Number range CHAPTER

**OPERATIONAL ACCEPTANCE**

**TEST PLAN**

for the

**Console Replacement System (CRS) Software Build 10.0**

and

**Voice Improvement Processor (VIP)**

**Software Build 3.1**

**August 2004**

![](media/image5.wmf){width="1.5in" height="1.5in"}

**U.S. DEPARTMENT OF COMMERCE**

**National Oceanic and Atmospheric Administration**

**National Weather Service/Office of Operational Systems**

**Field Systems Operations Center/Test and Evaluation Branch**

**(This Page Blank)**

**Table of Contents**[]{#__RefHeading___Toc76530941 .anchor}

[Page]{.underline}

Table of Contents [iii](#__RefHeading___Toc76530941)

Acronyms [v](#__RefHeading___Toc76530942)

1.0 Introduction [1](#__RefHeading___Toc76530943)

1.1 Test Plan Organization [1](#__RefHeading___Toc76530944)

1.2 Purpose [1](#__RefHeading___Toc76530945)

1.3 Test Objectives [2](#__RefHeading___Toc76530946)

1.4 Strategy [2](#__RefHeading___Toc76530947)

1.5 CRS Build 9.0/VIP Build 3.0 Contents
[3](#__RefHeading___Toc76530948)

1.6 Test Result Analysis [5](#__RefHeading___Toc76530949)

1.7 Test Review Group (TRG) [6](#__RefHeading___Toc76530950)

1.8 Prerequisites, Assumptions, and Risks
[8](#__RefHeading___Toc76530951)

1.8.1 Prerequisites [8](#__RefHeading___Toc76530952)

1.8.2 Assumptions [8](#__RefHeading___Toc76530953)

1.8.3 Risks [8](#__RefHeading___Toc76530954)

1.9 Test Personnel and Responsibilities [9](#__RefHeading___Toc76530955)

2.0 Method of Accomplishment [11](#__RefHeading___Toc76530956)

2.1 Test Sites [11](#__RefHeading___Toc76530957)

2.2 Test Methodology [11](#__RefHeading___Toc76530958)

2.2.1 Pre-OAT Activities [11](#__RefHeading___Toc76530959)

2.2.2 Test Configuration and Resources [12](#__RefHeading___Toc76530960)

2.2.2.1 Hardware/Software [12](#__RefHeading___Toc76530961)

2.2.2.2 Support Documentation [12](#__RefHeading___Toc76530962)

2.2.3 Installation [13](#__RefHeading___Toc76530963)

2.2.4 Test Conduct [13](#__RefHeading___Toc76530964)

2.2.5 Post-OAT Activities [14](#__RefHeading___Toc76530965)

2.3 Schedule [14](#__RefHeading___Toc76530966)

3.0 Test Recommendations and Report [17](#__RefHeading___Toc76530967)

**Tables**

[Page]{.underline}

[Table 1 - CRS Build 10.0/VIP 3.1 OAT Test Review Group (TRG) Personnel
6](#__RefHeading___Toc76530988)

[Table 2 - OAT Test Sites 11](#__RefHeading___Toc76530989)

[Table 3 - OAT Test Schedule 15](#__RefHeading___Toc76530990)

**Attachments**

[Attachment A - Test Trouble Report A-1](#__RefHeading___Toc78949160)

[Attachment B - CRS Build 10.0/VIP Build 3.1 Release Notes
B-1](#__RefHeading___Toc78949161)

[Attachment C - CRS Build 10.0/VIP Build 3.1 OAT Questionnaire
C-1](#Generated_Bookmark33)

[Attachment D - CRS Build 10.0/VIP Build 3.1 OAT Test Site Introduction
Agenda D-1](#__RefHeading___Toc78949163)

[Attachment E - Example VIP Remote SFTP Key Installation and Network
Setup E-1](#__RefHeading___Toc78949164)

**Acronyms**[]{#__RefHeading___Toc76530942 .anchor}

  ------------ ----------------------------------------------------------
  ACP          Audio Control Panel

  ASCII        American Standard Code for Information Interchange

  AWIPS        Advanced Weather Interactive Processing System

  CRS          Console Replacement System

  EAS          Emergency Alert System

  ECP          Engineering Change Proposal

  ECR          Engineering Change Request

  EO           Emergency Override

  FEP          Front End Processor

  FTP          File Transfer Protocol

  IP           Internet Protocol

  MIC          Meteorologist In Charge

  MP           Main Processor

  MP3          MPEG-2 Layer 3

  MPEG         Moving Pictures Expert Group

  NOAA         National Oceanic and Atmospheric Administration

  NWR          NOAA Weather Radio

  NWRSAME      NOAA Weather Radio Specific Area Message Encoder

  NWS          National Weather Service

  OAT          Operational Acceptance Test

  OTR          Operational Trouble Report

  SOM          System Operators Manual

  SFTP         Secure File Transfer Protocol

  ST           System Test

  SSH          Secure Shell

  SSO          Synthetic Speech Override

  TRG          Test Review Group

  TTR          Test Trouble Report

  TTS          Text-to-Speech

  VIP          Voice Improvement Processor

  WAV          Waveform audio

  WFO          Weather Forecast Office

  WSH          Weather Service Headquarters
  ------------ ----------------------------------------------------------

**1.0 Introduction**[]{#__RefHeading___Toc76530943 .anchor}

This plan describes the Government tests planned during the Operational
Acceptance Test (OAT) of the National Oceanic and Atmospheric
Administration (NOAA) Weather Radio (NWR) Console Replacement System
(CRS) Build 10.0 and the Voice Improvement Processor (VIP) Build 3.1
software. The OAT is intended to verify the installation of the CRS
Build 10.0/VIP Build 3.1 software and confirm the successful operation
in the National Weather Service's (NWS) Weather Forecast Offices (WFOs)
prior to nationwide deployment.

The CRS Build 10.0/VIP Build 3.1 software contains 10 software
enhancements and 16 software fixes (see Section 1.5), including
automatic CRS and VIP user's password checking, secure file transfers
using the Secure File Transfer Protocol (**sftp**), and authenticated
secure shell (**ssh**) key installations.

A System Test (ST) will be performed at the NWS Headquarters (WSH)
located in Silver Spring, Maryland. Upon successful completion of the
ST, the CRS Build 10.0/VIP Build 3.1 software will be shipped to four
selected WFOs, one each from the continental US regions (see Section
2.1), for an OAT. The OAT will be conducted from August 9 through
September 17, 2004, for at least 30 days of operations. Upon OAT
completion, an OAT Report will contain a recommendation whether to
proceed with the national deployment of CRS Build 10.0/VIP Build 3.1
software.

An OAT Test Review Group (TRG) (see Section 1.7) will be established for
the duration of the CRS Build 10.0/VIP Build 3.1 OAT. The TRG will
expeditiously review OAT activities, coordinate issues, and classify any
problems identified during the OAT for resolution. Problems that are
identified during the OAT will be documented in Test Trouble Reports
(TTRs) (see Attachment A). The TRG will also provide NWS management with
a recommendation whether to proceed with national deployment.

**1.1 Test Plan Organization**[]{#__RefHeading___Toc76530944 .anchor}

This OAT plan is comprised of three sections. Section 1.0 contains
introductory material dealing with CRS Build 10.0/VIP Build 3.1
contents, the test strategy, test objectives, and test prerequisites.

Section 2.0 describes the schedule and methodology for conducting the
OAT, and the pre- and post-test activities performed at the OAT site
test facilities. This section also contains information on test
personnel and their responsibilities.

Section 3.0 discusses how a recommendation for OAT will be made and how
the test report will be written.

**1.2 Purpose**[]{#__RefHeading___Toc76530945 .anchor}

The CRS Build 10.0/VIP Build 3.1 OAT will verify the installation and
operation of the software upgrade in NWS field offices. The OAT will
ensure the upgrade does not adversely affect current operations. The OAT
will determine whether the new software is ready for deployment to the
remainder of the NWS sites.

The OAT will allow the OAT sites to verify the introduction of new
security features in CRS and VIP. These features include automatic
user's password checking, authenticated **ssh** key installations,
**sftp** file transfer processing within CRS and VIP, and **sftp**
remote file transfers for field sites performing VIP remote file
transfers.

**1.3 Test Objectives**[]{#__RefHeading___Toc76530946 .anchor}

The specific objectives of this OAT are to:

> a\. Verify the EHB-7 Software Note 6 document instructions for the
> installation of CRS Build 10.0 and the VIP Build 3.1 software are
> complete and accurate.
>
> b\. Verify, in an operational environment, successful operation of the
> CRS Build 10.0 and the VIP Build 3.1 software without any system
> degradation.
>
> c\. Verify the required CRS Build 10.0/VIP Build 3.1 documents are
> adequate (e.g., Release Notes, etc).
>
> d\. Verify the CRS and VIP automatic user's password handling is
> adequate and operational.
>
> e\. Verify the ingest of input messages into CRS, conversion
> processing with the VIP, and subsequent broadcast are operational
> without any system degradation.

f\. Verify any problems found during VIP remote site file transfers, per
specifically designated OAT sites performing such functionality, are
mitigated and/or supported for operational status without any system
degradation.

g\. Verify the NWRSAME test event (e.g., DMO) does not incur any
problems during test transmission.

**1.4 Strategy**[]{#__RefHeading___Toc76530947 .anchor}

The OAT will be conducted at four WFOs, with sites performing VIP remote
file transfer processing, using their operational CRS and VIP systems.
During the OAT, sites will use their current Advanced Weather
Interactive Processing System (AWIPS) and the associated message
formatters to receive and send data and products for English and/or
Spanish messages.

The OAT will begin by assessing the installation of the software
upgrades. During the first week of the OAT, the OPS24 and OPS23 support
team will be on-site to monitor and assist the OAT site personnel during
installation. The OAT site personnel will assess the work required to
update system passwords for each of the CRS and VIP processors and to
install the required **ssh** keys used for CRS and VIP secure file
transfers. The **sftp** processing between CRS and VIP should be
transparent to the operator. There should be no degradation of message
file transfers during message input and subsequent broadcast.

For OAT sites using VIP remote file transfers, the OAT will assess
possible system degradation due to the introduction of **sftp** instead
of **ftp** file transfer handling. The OPS23 software branch will help
support the sites immediately affected by the **ftp** to **sftp**
transition. During the OAT, the OPS24 test and evaluation branch will
document, in addition to other related OAT test results, site
resolutions regarding remote file transfers. These documented
resolutions will be verified and, upon TRG adjudication, disseminated by
OPS23 to the WFOs with similar VIP remote file transfer methodologies.

**1.5 CRS Build 10.0/VIP Build 3.1
Contents**[]{#__RefHeading___Toc76530948 .anchor}

The CRS Build 10.0/VIP Build 3.1 software contains 10 software
enhancements and 16 software fixes (see Attachment B), including
automatic user's password checking, CRS and VIP secure file transfers
using **sftp**, authenticated **ssh** key installations, VIP remote file
transfers using **sftp**, and the NWRSAME DMO event test capability. The
major CRS Build 10.0/VIP Build 3.1 software enhancements include:

a.  The password handling will be in compliance with the Department of
    Commerce secure password policies including the automatic 90-day
    change prompt and the password update restrictions. The following
    CRS Master Processors (MPs) and Front End Processors (FEPs), and VIP
    automatic password restrictions include:

    i.  Password must have at least 8 non-blank characters.

    ii. Password must contain at least one alphabetic character.

    iii. Password must contain at least one number.

    iv. Password must have at least 3 different characters from the old
        password.

    v.  Number range CHAPTERPassword must differ from the user name, any
        circular shift of the user name, reverse order of the user name,
        or any reverse circular shift of the user name. Please note that
        all CRS user accounts contain fewer than 8 characters.
        Therefore, having the user name as the password will fail on the
        restriction described above in (i).

    vi. Password must be changed at least every 90 days.

Additionally, the VIP automatic password restrictions will include:

vii. Password must contain at least one upper case alphabetic character.

viii. Six of the characters may occur only once in the password.

ix. Number range CHAPTERIn addition to the current password, the
    password cannot be changed to the 10 previous passwords. Therefore,
    the current password will not be able to be re-used for the next 11
    password changes.

x.  Password cannot contain vendor/manufacturer default passwords, words

> found in any dictionary (forward or backward), addresses, birthdays,
> or common character sequence
>
> Due to the limited capabilities of the current CRS operating system
> (UnixWare 7), the CRS password handling will also involve
> non-automatic manual enforcement of user password changes. These CRS
> manual user password change restrictions include Items **vii-x**. For
> both CRS and VIP systems, another manual user password restriction is
> to disallow the use of special characters (e.g., \# \* @ &, etc.).

b.  The CRS Build 10.0/VIP Build 3.1 was originally designed to expect
    AWIPS to have a concurrent **sftp** implementation of their message
    file transfers to CRS. However, according to the latest CRS Build
    10.0 release notes:

    **"...LATEST AWIPS UPDATE: PLEASE NOTE THAT BECAUSE OF AWIPS LOADING
    PROBLEMS, AWIPS OB4 WILL NOT BE IMPLEMENTING SFTP. TRANSACTIONS FROM
    AWIPS TO CRS WILL CONTINUE TO USE FTP..."**

> Nevertheless, the CRS will process the normal VIP conversion file
> transfers, using **sftp**, between CRS and VIP only. The CRS will
> continue to properly handle incoming AWIPS messages transferred via
> the current **ftp** protocol. The use of **sftp** between CRS and VIP
> will be transparent and will not incur any limitations, including any
> communication issues with the current AWIPS **ftp** handling.
>
> In order to avoid the use of clear text logins between CRS and VIP
> processors, the CRS Build 10.0/VIP 3.1 will use authenticated keys
> created and distributed during the initial software installation.
> Steps taken during installation ensure keys will be properly created
> and copied to specified processors (see Attachment B, ECR 804).

c.  The VIP remote file transport processing will now use the **sftp**
    processing to transfer the VIP-generated Microsoft waveform
    (**WAV**) audio files and/or Moving Pictures Expert Group Level 3
    (**MP3**) compressed audio files to a field-designated destination
    computer. **All VIP remote sftp users must convert to a standard
    configuration which is supported by CRS Build 10.0/VIP Build 3.1.
    The VIP Build 3.1 software requires OAT sites to transfer VIP
    messages from VIP to the LDAD Server (LS1). These messages will then
    either be transferred to an external system or an external system
    will retrieve the messages from the LS1. The transfer or retrieval
    of VIP WAV or MP3 files will be an OAT site designated method and
    the setup and configuration will be performed by OAT site
    personnel.**

d.  The NWRSAME tone will now have the DMO test event capability. The
    CRS software will check for the new DMO event code on input and will
    subsequently generate the "999000" location test code instead of
    actual county codes. This will enable NWS field offices to practice
    issuing critical messages without disrupting the Emergency Alert
    System (EAS) network or turning on receiver codes.

The CRS Build 10.0 software also contains a functionality to accept the
input of externally generated voice files (WAV files) into CRS. However,
this functionality has been deactivated and according to the latest CRS
Build 10.0 release notes:

> "...Number range CHAPTER**THIS FEATURE WILL NOT BE ACTIVATED IN BUILD
> 10.0. IF CRS BUILD 10.0 RECEIVES AN EXTERNALLY GENERATED VOICE
> MESSAGE, AN ALERT MONITOR ERROR MESSAGE WILL BE GENERATED AND THE
> MESSAGE WILL BE DELETED. IF THIS CAPABILITY IS NEEDED IN THE FUTURE TO
> SUPPORT THE ALL HAZARDS COLLECTION SYSTEM, IT WILL BE ACTIVATED AT
> THAT TIME..."**

**1.6 Test Result Analysis**[]{#__RefHeading___Toc76530949 .anchor}

The staff at the OAT sites will provide comments on the installation
process and operational use of the new software and VIP (see Attachment
C) including any problems encountered. If problems are observed, the OAT
site staff will write TTRs (see Attachment A) to document each problem
and send (either email or fax) these TTRs to the Test Director. The Test
Director will collect the TTRs and add them to the **TestTrack**
database. The Test Director will provide the TTRs to the Test Review
Group for adjudication (see Section 1.7).

The **TestTrack** database has recently been updated to document TTRs,
which will include, among other relevant problem information, the
**Impact** and the **Priority** of each TTR. The **Impact** field deals
with how each problem affects the overall broadcast mission. The problem
can be assigned (sorted in ascending severity):

> Impact 1 -- prevent message broadcast, no workaround
>
> Impact 2 -- prevent broadcast with reasonable workaround
>
> Impact 3 -- degradation of broadcast
>
> Impact 4 -- less critical -- loss of minimum capability
>
> Impact 5 -- minimum to no impact, nice to have.

The **Priority** field deals with how the problem is planned to be
resolved. The problem can be assigned (sorted in ascending severity):

> Priority 1 -- need immediate emergency fix
>
> Priority 2 -- include in the next build
>
> Priority 3 -- include in future build
>
> Priority 4 -- requires replacement system
>
> Priority 5 -- undetermined

If a problem is assigned a **Priority** of **1**, an immediate
suspension of the OAT will result and the TRG will assign the problem
resolution to the responsible personnel. If the problem in question has
been deemed resolved by the TRG, the OAT will resume and any further
regression testing will be performed.

**1.7 Test Review Group (TRG)**[]{#__RefHeading___Toc76530950 .anchor}

The TRG will assist in problem resolution during the OAT. The TRG is
comprised of a group of subject-matter experts and is chaired by the
Chief, Test and Evaluation Branch (OPS24). The role of the TRG is to
evaluate each TTR's impact on daily field service operations and make
recommendations to the CRS/VIP Software Manager on TTR criticality. The
TRG is comprised of the personnel from the offices identified in
Table 1. Following completion of the OAT, the TRG will convene to review
the findings and recommend whether to proceed with national
implementation.

[]{#__RefHeading___Toc76530988 .anchor}Table 1 - CRS Build 10.0/VIP 3.1
OAT Test Review Group (TRG) Personnel

+-------------------+-----------------------------+------------+------+
| **Na              | **Function**                | **Phone**  | **Vo |
| me/Organization** |                             |            | ting |
|                   |                             |            | Memb |
|                   |                             |            | er** |
+===================+=============================+============+======+
| Jerald Dinges     | Test Review Group Chair     | 30         | Nu   |
| (OPS24)           |                             | 1-713-0326 | mber |
|                   |                             | x160       | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Bert Viloria      | OAT Test Director           | 30         |      |
| (OPS24)           |                             | 1-713-0326 |      |
|                   |                             | x131       |      |
|                   |                             |            |      |
|                   |                             | *FAX:*     |      |
|                   |                             | 30         |      |
|                   |                             | 1-713-0912 |      |
+-------------------+-----------------------------+------------+------+
| Mary Buckingham   | OAT Support                 | 30         |      |
| (OPS24)           |                             | 1-713-0326 |      |
|                   |                             | x137       |      |
+-------------------+-----------------------------+------------+------+
| Harry Tran        | OAT Support                 | 30         |      |
| (OPS24)           |                             | 1-713-0326 |      |
|                   |                             | x105       |      |
+-------------------+-----------------------------+------------+------+
| Jae Lee (OPS24)   | OAT Support                 | 30         |      |
|                   |                             | 1-713-0326 |      |
|                   |                             | x158       |      |
+-------------------+-----------------------------+------------+------+
| Joel Nathan       | CRS/VIP Software Manager    | 30         | Nu   |
| (OPS23)           |                             | 1-713-0191 | mber |
|                   |                             | x119       | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Jeff Earl (OPS12) | Maintenance Assurance       | 30         |      |
|                   |                             | 1-713-1833 |      |
|                   |                             | x162       |      |
+-------------------+-----------------------------+------------+------+
| Harvey Thurm      | Eastern Region Program      | 63         | Nu   |
| (ER1)             | Manager                     | 1-244-0124 | mber |
|                   |                             |            | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Mike Mach (SR)    | Southern Region Program     | 81         | Nu   |
|                   | Manager                     | 7-978-1100 | mber |
|                   |                             | x108       | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Greg Noonan(CR4)  | Central Region Program      | 81         | Nu   |
|                   | Manager                     | 6-891-7734 | mber |
|                   |                             | x301       | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Craig Schmidt     | Western Region Program      | 80         | Nu   |
| (WR1)             | Manager                     | 1-524-4000 | mber |
|                   |                             | x266       | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Per Pedersen      | Alaska Region Program       | 90         | Nu   |
| (AR41)            | Manager                     | 7-271-3462 | mber |
|                   |                             |            | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| Jay DelCano       | Pacific Region Program      | 80         | Nu   |
| (PR11)            | Manager                     | 8-532-6427 | mber |
|                   |                             |            | r    |
|                   |                             |            | ange |
|                   |                             |            | CHAP |
|                   |                             |            | TER |
+-------------------+-----------------------------+------------+------+
| **Philadelphia PA | Focal Points \[Input To     | 60         |      |
| WFO (PHI)**       | Region Prog. Manager\]      | 9-261-6600 |      |
|                   |                             |            |      |
| > Gary Szatkowski | *MIC*                       |            |      |
|                   |                             |            |      |
| Joseph Byerly     | *ESA*                       |            |      |
|                   |                             |            |      |
| Roy Miller        | *DAPM*                      |            |      |
|                   |                             |            |      |
| Dan Hagarty       | *ITO*                       |            |      |
+-------------------+-----------------------------+------------+------+
| **Austin / San    | Focal Points \[Input To     | 83         |      |
| Antonio TX WFO    | Region Prog. Manager\]      | 0-606-3617 |      |
| (EWX)**           |                             |            |      |
|                   | *MIC*                       |            |      |
| > Joe Arellano    |                             |            |      |
|                   | *ESA*                       |            |      |
| Brian Read        |                             |            |      |
|                   | *DAPM*                      |            |      |
| William Runyon    |                             |            |      |
|                   | *ITO*                       |            |      |
| Mark Oliver       |                             |            |      |
+-------------------+-----------------------------+------------+------+
| **Northern        | Focal Points \[Input To     | 57         |      |
| Indiana IN WFO    | Region Prog. Manager\]      | 4-834-1104 |      |
| (IWX)**           |                             |            |      |
|                   | *MIC*                       |            |      |
| > Mike Sabones    |                             |            |      |
|                   | *ESA*                       |            |      |
| Peter Wallace     |                             |            |      |
|                   | *DAPM*                      |            |      |
| Terry Click       |                             |            |      |
|                   | *ITO*                       |            |      |
| Dereek Adams      |                             |            |      |
+-------------------+-----------------------------+------------+------+
| **San Diego CA    | Focal Points \[Input To     | 85         |      |
| WFO (SGX)**       | Region Prog. Manager\]      | 8-675-8700 |      |
|                   |                             |            |      |
| > Jim Purpura     | *MIC*                       |            |      |
|                   |                             |            |      |
| Mike Lauderdale   | *ESA*                       |            |      |
|                   |                             |            |      |
| Michael Khuat     | *ITO*                       |            |      |
+-------------------+-----------------------------+------------+------+

**1.8 Prerequisites, Assumptions, and
Risks**[]{#__RefHeading___Toc76530951 .anchor}

This section describes the actions required before the OAT, the
availability of other equipment needed for the OAT, and a description of
the risks associated with performing the OAT.

**1.8.1 Prerequisites**[]{#__RefHeading___Toc76530952 .anchor}

> a\. The OPS24 conducts and successfully completes a CRS Build 10.0/VIP
> Build 3.1 System Test. All TTRs classified as **Impact 1** and **2**
> must be closed.
>
> b\. Draft versions of all CRS Build 10.0/VIP Build 3.1 documentation
> are available including EHB-7 Software Note 6, CRS Build 10 System
> Operators Manual, and CRS Build 10.0/VIP Build 3.1 Release Notes (see
> **2.2.2.2 Support Documentation**) and provided to the OAT site.
>
> c\. An OAT Test Readiness Review is conducted and the TRG agrees the
> system is ready to begin the OAT. The Oat Test Readiness Review occurs
> on the same day as the CRS Build 10.0/VIP Build 3.1 ST wrap-up
> meeting.

d\. For OAT sites using the VIP remote ftp file transfers, the OAT site
personnel will reconfigure their external remote systems to support
**ssh**/**sftp** file transfers. **All VIP remote sftp users must
convert to a standard configuration which is supported by CRS Build
10.0/VIP Build 3.1. The VIP Build 3.1 software requires OAT sites to
transfer VIP messages from VIP to the LDAD Server (LS1). These messages
will then either be transferred to an external system or an external
system will retrieve the messages from the LS1. The transfer or
retrieval of VIP WAV or MP3 files will be an OAT site designated method
and the setup and configuration will be performed by OAT site
personnel.**

**1.8.2 Assumptions**[]{#__RefHeading___Toc76530953 .anchor}

> Training for CRS Build 10.0/VIP Build 3.1 is not required for
> installation, configuration, operational use, and maintenance of the
> systems.

**1.8.3 Risks**[]{#__RefHeading___Toc76530954 .anchor}

> The risks involved in the OAT are:

a.  **[The creation and distribution of the ssh key
    files]{.underline}**. The introduction of authenticated **ssh** keys
    within CRS and VIP will now allow files to be distributed
    non-interactively (no user and password prompts) via the
    **authorized_keys** file. If the **authorized_keys** file is somehow
    inadvertently corrupted, deleted, or updated, files transfer
    problems could occur. Moreover, a misleading VIP 'down' status may
    also occur due to the non-delivery of the VIP status file.

b.  **[No standard VIP remote file transfer configuration or specific
    NWR requirements for VIP remote file transfer
    processing]{.underline}**. The VIP remote file transfer, while still
    considered an external functionality of CRS, will now require the
    external remote machine to have an **ssh** configuration which
    supports **sftp**. This remote machine is where the VIP **WAV** or
    **MP3** files are to be transferred. Currently, there are no
    standard requirements on how external remote machines are
    configured. Each site using the remote transfer could have external
    systems that have different operating systems and security settings.

> Additionally, the VIP Build 3.1 software has been rewritten without a
> fallback switch to the former **ftp** processing if the **sftp** or
> **ssh** configurations do not exist and are not set properly. Fallback
> switch procedures do not exist because this VIP remote file transfer
> is NOT a NWR requirement.
>
> **The VIP remote sftp messages must be sent from the VIP to the LDAD
> server (see Section 1.5, Part c)**. Subsequently, these messages on
> the LDAD server must be *sent to* or *retrieved by* an external
> machine. There are no standard requirements for how these LDAD server
> VIP messages are going to be sent to the external machine.

c.  **[New NWRSAME DMO test event code]{.underline}**. The new NWRSAME
    **DMO** event code will now allow the capability to conduct
    exercises without disrupting the EAS network or turning on receiver
    codes used by industry and the general public (see Attachment B, ECR
    831). Specifically, the "999000" value will now be used instead of
    the valid UGC values corresponding to specific county codes.
    Additionally, the DMO event code will not trigger audio alarms.

> The new DMO feature requires the DMO message type will be created and
> scheduled for specified transmitters for testing. Additionally, all
> NWRSAME decoders nationwide rely on proper alignment of data values
> per the frequency-shifted data tone. Since the DMO **999000** code
> replaces actual county codes, the DMO NWRSAME tone transmission should
> be verified for non-activation of NWRSAME receivers and any audio
> alarms.

**1.9 Test Personnel and
Responsibilities**[]{#__RefHeading___Toc76530955 .anchor}

The personnel participating in the OAT are listed in Table 1. Selected
personnel from OPS23 will also participate and will be responsible for
OAT support. The following describes the major roles and
responsibilities of the test personnel.

**[Test Review Group Chair]{.underline}** (OPS24) - Convenes the weekly
TRG meetings by conference calls (see Table 3 -- OAT Test Schedule) to
review, clarify, and validate deficiencies documented in TTRs.
Categorizes validated deficiencies and recommends corrective actions to
the CRS/VIP Software Manager. Coordinate the prioritization and
resolution of validated deficiencies and of other test-related issues.
The Test Review Group Chair is a voting member of the TRG.

**[Test Director]{.underline}** (OPS24) - Ensures all tests defined for
the OAT are completed and the results properly documented in the OAT
report. Responsible for collecting and presenting TTRs to the TRG for
classification. Coordinates OAT conference calls. Following completion
of the OAT, the Test Director will call a final meeting of the TRG,
detail to the CRS/VIP Software Manager what was tested, and report the
OAT conclusions. Ensures all TTRs documented and classified during the
OAT are forwarded to the proper WSH organization or board for
adjudication; writes the OAT report to document the test results and
recommendations. The Test Director is a member of the TRG.

**[CRS/VIP Software Manager]{.underline}** (OPS23) - Ensures the CRS
Build 10.0/VIP Build 3.1 software and documentation are available for
the OAT. Participates in OAT conference calls. Reviews all problems
documented and classified during the OAT and coordinates their
adjudication. Reviews the OAT plan and report. The CRS/VIP Software
Manager is a voting member of the TRG.

**[OAT Support]{.underline}** (OPS24) - Responsible for performing test
support duties as assigned; assists test sites in completing TTRs when
problems are observed; provides the Test Director with technical
information and advises on problem solutions. OAT support team will also
monitor and assist during the OAT site software installation. The team
members are members of the TRG.

**[Regional CRS Focal Points]{.underline}** - Responsible for providing
coordination between WFOs and WSH, participating in conference calls,
and reviewing plans and reports during the OAT. The regional CRS focal
points are voting members of the TRG.

**[OAT Sites]{.underline}** - Responsible for planning and coordinating
OAT activities with their regional CRS Focal Points and WSH,
participating in conference calls, and reviewing of plans and reports
during the OAT. The test site Meteorologist in Charge (MIC) will approve
decisions required during the OAT, for example, when to install the
equipment, how to operate with the new system, and ensure the OAT site
staff support as required. **The OAT site MIC retains all management
responsibility for the site including whether to continue the OAT**. The
OAT site will provide at least one site representative to participate in
the OAT conference calls. OAT site personnel will:

> \- perform the software installation with assistance from OAT Support
> team.

\- configure VIP remote file transfer operations

> \- provide installation feedback to the Test Director
>
> \- verify CRS, VIP and NWR operations
>
> \- note any problems on TTR forms (Attachment A)
>
> \- provide input during OAT at TRG conference calls
>
> \- complete and return questionnaire to OAT Test Director (Attachment
> C)

**2.0 Method of Accomplishment**[]{#__RefHeading___Toc76530956 .anchor}

The following sections describe the test schedule, facilities,
configuration, resources, and personnel roles and responsibilities to
conduct the OAT.

**2.1 Test Sites**[]{#__RefHeading___Toc76530957 .anchor}

The four WFO OAT test sites include:

[]{#__RefHeading___Toc76530989 .anchor}Table 2 - OAT Test Sites

  ---------------------------------- ------------------- ------------------
  **Site**                           **Configuration**   **Transmitters**

  ER - Philadelphia, PA (PHI)        Large               7

  SR -- Austin / San Antonio TX      Max                 12
  (EWX)                                                  

  CR - Northern Indiana IN (IWX)     Typical             4

  WR - San Diego CA (SGX)            Large               6
  ---------------------------------- ------------------- ------------------

**2.2 Test Methodology**[]{#__RefHeading___Toc76530958 .anchor}

The following sections describe how the OAT will be conducted. The Test
Director will ensure the test is performed as outlined. Any deviation
from the test methodology will be documented and provided to the OAT
Support Team prior to conduct of the affected tests.

**2.2.1 Pre-OAT Activities**[]{#__RefHeading___Toc76530959 .anchor}

> **[WSH]{.underline}** - Prior to conducting the OAT, WSH will complete
> the following actions:
>
> a\. Conduct a successful CRS Build 10.0/VIP Build 3.1 ST. - OPS24
>
> b\. Distribute the OAT Plan to each OAT site. - OPS24
>
> c\. Package and ship CRS Build 10.0/VIP Build 3.1 software with all
> documentation to the OAT sites. - OPS23 (see Section 2.2.2.2)
>
> **[OAT Sites]{.underline}** - Prior to conducting the OAT, OAT sites
> will complete the following actions:

a\. The OAT sites will ensure NWR/CRS is optimally functioning.

b\. Save the current configuration of CRS and VIP dictionary and
preprocessor files on removable media for backup.

c\. The OAT sites will ensure required software, including the VIP disk
image CDs, are available.

d\. For OAT sites using VIP remote ftp file transfers, the OAT sites
will ensure the remote machines are preconfigured with **ssh**/**sftp**
capabilities. Additionally, OAT sites must convert to a standard
configuration which is supported by CRS Build 10.0/VIP Build 3.1. The
VIP Build 3.1 software requires OAT sites to transfer VIP messages from
VIP to the LDAD Server (LS1). These messages will then either be
transferred to an external system or an external system will retrieve
the messages from the LS1. The transfer or retrieval of VIP WAV or mp3
files will be an OAT site designated method and the setup and
configuration will be performed by OAT site personnel.

**2.2.2 Test Configuration and Resources**[]{#__RefHeading___Toc76530960
.anchor}

The following sections describe the CRS test configuration, supporting
documentation, and test personnel roles and responsibilities.

**2.2.2.1 Hardware/Software**[]{#__RefHeading___Toc76530961 .anchor}

A fully configured CRS complete with a VIP system will be used at each
test site WFO during the OAT. The WFO AWIPS will be used to send
formatted messages to the CRS. Each WFO's normal transmitters will be
used to send CRS message products to the public as it is currently
implemented.

For OAT sites using the VIP remote ftp functionality, each site will
setup the required **ssh** configuration on its remote machine to allow
**sftp** file transfers from the VIP. **All VIP remote sftp users must
convert to a standard configuration which is supported by CRS Build
10.0/VIP Build 3.1 (see Section 1.5, Part c).**

**2.2.2.2 Support Documentation**[]{#__RefHeading___Toc76530962 .anchor}

CRS and VIP support documentation hardware/software installation, and
operational instructions will be shipped to each OAT site prior to the
OAT. Reference to these documents will be made as required throughout
the test. The list of documentation, procedures and responsible authors
includes, but is not limited to, the following:

> \- OAT Plan for the CRS Build 10.0/VIP Build 3.1 (OPS24)
>
> \- EHB-7 Software Note 6 (OPS23/OPS12)

\- CRS Build 10.0 Release Notes (draft) (OPS23)

\- VIP Build 3.1 Release Notes (draft) (OPS23)

\- Equipment Maintenance Reporting System (EMRS) Instructions (OPS13)

\- CRS Build 10.0 System Operators Manual (SOM) (OPS23)

The CRS Build 10.0 SOM document will only be included as a "**.pdf**"
file within the CRS Build 10.0 software distribution CDs. The EMRS
instructions document will be included within the EHB-7 Software Note 6
document.

**2.2.3 Installation**[]{#__RefHeading___Toc76530963 .anchor}

WSH will ship the CRS Build 10.0/VIP Build 3.1 software and
documentation to the test sites or take them to the OAT site before the
OAT begins. The OAT site personnel will have the necessary support
software, including the VIP disk image CDs, to proceed with
installation. OAT site personnel will perform the installation of the
CRS Build 10.0/VIP Build 3.1 software in accordance with the EHB-7
Software Note 6 installation instructions. The OAT Support team (OPS24
and OPS23) will provide assistance during installation. Also, at this
time, the OAT site personnel will evaluate and forward comments to the
OAT Test Director. **The OAT test sites must wait to install the CRS
Build 10.0/VIP Build 3.1 software until the Test Director authorizes
them to begin**. At the end of an installation, the OAT site personnel
will complete EMRS in accordance with the EMRS Instructions.

**2.2.4 Test Conduct**[]{#__RefHeading___Toc76530964 .anchor}

The OAT Test Director and OAT Support personnel will be on site at the
WFOs in the first week of the OAT. The CRS/VIP Software Manager will
send the new software builds and documentation to the OAT test sites.
The Test Director will notify the test sites when they may begin the
installation. **The OAT site MIC retains control over the operations of
the site including whether to halt the OAT.**

If operational concerns affect the agreed installation times, the site
must notify the OAT Test Director and reschedule the CRS Build 10.0/VIP
Build 3.1 installation. Prior to actual OAT tests, the WSH personnel
will meet with the OAT site personnel (see Attachment D) to discuss the
OAT test agenda. The OAT will be conducted by OAT site personnel
performing routine daily operations with the CRS and VIP systems.

During the OAT, the following actions will be performed:

> a\. OAT site personnel will install the CRS Build 10.0 and the VIP 3.1
> software.
>
> b\. OAT site personnel will operate CRS Build 10.0/VIP Build 3.1 in
> normal and backup CRS/NWR service operations.
>
> c\. OAT site personnel will update all the CRS and VIP user's
> passwords per the new CRS and VIP password policies (see Section 1.5).

d\. OAT site personnel will create and copy the authenticated **ssh**
key files to all appropriate CRS and VIP processors.

e\. For OAT sites using VIP remote ftp file transfers, OAT personnel
will setup their remote machine for **ssh** configuration and allow for
**sftp** file transfers from VIP. The OAT personnel will test the new
remote **sftp** file transfers and verify the **WAV** and/or **MP3**
files are properly copied to the remote machine (see Section 1.5, Part
c).

f\. OAT site personnel will test the new NWRSAME **DMO** test tone
functionality and verify the test event code does not trigger audio
alarms. For OAT sites having either the MTR-4407 or the DCR-450 NWRSAME
decoders, the OAT site personnel will verify the data NWRSAME tone
output containing the "999000" value instead of the actual UGC county
codes.

For OAT sites using the VIP remote file transfers, the OAT site
personnel must copy the proper authenticated **ssh** key files. For
Linux-based external systems, the OAT site personnel must copy the VIP
**/home/crs/.ssh/vip.pub** key file to the authorized external system.
The OAT site personnel operator should coordinate this **ssh** key file
copy with the System Administrator of the authorized external system.
Normally, the **vip.pub** public key file would be added to an
**authorized \_keys** file or its equivalent. **All VIP remote sftp
users must convert to a standard configuration which is supported by CRS
Build 10.0/VIP Build 3.1 (see Section 1.5, Part c).** A step-by-step
example for setting up the key installation and network setup for the
file transfer of VIP messages to the LDAD server is included in
Attachment E.

For OAT sites using the former VIP remote **ftp** file transfers, the
new **sftp** file transfer capability might present some problems and/or
additional work to reconfigure**. In order to minimize the impact of the
external system down time, the PHI WFO will be one of the initial OAT
sites for the first week of the OAT (August 9^th^) performing
installation and testing.** At the PHI WFO site, the WSH and OAT site
personnel will coordinate and gather VIP remote sftp file transfer
information during testing. After a successful setup of the remote file
transfer, relevant information will be verified, and upon agreement
during the TRG weekly meetings, these data will be disseminated to the
rest of the OAT sites. Subsequently, the WSH test team will proceed to
the rest of the sites and resume OAT testing.

**A single point of contact for OAT telephone support is at WSH OPS24:
301-713-0326 x 131 Bert Viloria or email to Bert.Viloria@noaa.gov.** Any
problems observed during the OAT will be documented on a TTR (Attachment
A) and called to the immediate attention of the OAT Test Director. TTRs
may be **faxed to 301-713-0912.** The Test Director will present the
TTRs to the TRG for classification and recommendations for further
action. Any CRS/VIP operational issues can also be directed to **WSH
OPS23: 301-713-0191 x119 Joel Nathan or 301-713-0191 x139 Nancy
Helderman** with support available weekdays from 6:15 a.m. to 5:00 p.m.
EST. The CRS Help Desk can also be accessed from the Internet at
<http://weather.gov/ops2/crs/crshelp.html>

**2.2.5 Post-OAT Activities**[]{#__RefHeading___Toc76530965 .anchor}

Following completion of the OAT, the OAT Test Director will conduct a
final meeting of the TRG to review test activities, a summary of TTRs
found, major findings, and recommendations. The TRG will review the
materials presented by the Test Director and make a recommendation to
the CRS/VIP Software Manager whether to proceed with the national
deployment.

**2.3 Schedule**[]{#__RefHeading___Toc76530966 .anchor}

The OAT will be conducted in accordance with the following schedule:

[]{#__RefHeading___Toc76530990 .anchor}Table 3 - OAT Test Schedule

+--------+-------------------------------------------------------------+
| **     | **Action**                                                  |
| Date** |                                                             |
+========+=============================================================+
| 08     | 2PM EST; First OAT conference call, in conjunction with     |
| /05/04 | final ST wrap-up and OAT Test Readiness Review.             |
+--------+-------------------------------------------------------------+
| 08     | The OAT sites MUST have already received the CRS Build      |
| /09/04 | 10.0/VIP Build 3.1 software and documentation.              |
|        |                                                             |
|        | **PHI install & setup** CRS Build 10.0/VIP Build 3.1        |
|        | software                                                    |
|        |                                                             |
|        | \- Install software and red-line installation Instructions  |
|        |                                                             |
|        | \- If time permitting, test the VIP remote sftp file        |
|        | transfers.                                                  |
|        |                                                             |
|        | \- Provide installation process feedback to OAT Test        |
|        | Director                                                    |
+--------+-------------------------------------------------------------+
| 08     | **EWX install & setup** CRS Build 10.0/VIP Build 3.1        |
| /10/04 | software                                                    |
|        |                                                             |
|        | \- Install software and red-line installation Instructions  |
|        |                                                             |
|        | \- Provide installation process feedback to OAT Test        |
|        | Director                                                    |
|        |                                                             |
|        | \- Sites continue CRS/VIP operations                        |
+--------+-------------------------------------------------------------+
| 08     | **PHI and EWX Routine Weekly Test**, including the          |
| /11/04 | following tests:                                            |
|        |                                                             |
|        | \- NWRSAME DMO tone test                                    |
|        |                                                             |
|        | \- Start or resume scheduled tests from previous day.       |
+--------+-------------------------------------------------------------+
| 08     | 2PM EST; conference call, review activities.                |
| /12/04 |                                                             |
+--------+-------------------------------------------------------------+
| 08     | **IWX and SGX install & setup** CRS Build 10.0/VIP Build    |
| /17/04 | 3.1 software                                                |
|        |                                                             |
|        | \- Install software and red-line installation Instructions  |
|        |                                                             |
|        | \- If time permitting, test the VIP remote sftp file        |
|        | transfers.                                                  |
|        |                                                             |
|        | \- Provide installation process feedback to OAT Test        |
|        | Director                                                    |
|        |                                                             |
|        | \- Sites continue CRS/VIP operations.                       |
+--------+-------------------------------------------------------------+
| 08     | **Routine Weekly Tests**. For the test of the OAT sites:    |
| /18/04 |                                                             |
|        | \- NWRSAME DMO tone test                                    |
|        |                                                             |
|        | \- Externally generated voice message input to CRS          |
|        |                                                             |
|        | \- Start or resume scheduled tests from previous day.       |
+--------+-------------------------------------------------------------+
| 08     | 2PM EST; conference call, review activities.                |
| /19/04 |                                                             |
+--------+-------------------------------------------------------------+
| 08     | Routine Weekly Test.                                        |
| /25/04 |                                                             |
+--------+-------------------------------------------------------------+
| 08     | 2PM EST; conference call, review OAT activities             |
| /26/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | Routine Weekly Test                                         |
| /01/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | 2PM EST; conference call, review OAT activities             |
| /02/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | Routine Weekly Test                                         |
| /08/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | 2PM EST; conference call, review OAT activities             |
| /09/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | Routine Weekly Test.                                        |
| /15/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | 2PM EST; conference call, review OAT activities             |
| /16/04 |                                                             |
+--------+-------------------------------------------------------------+
| 09     | End of OAT.                                                 |
| /17/04 |                                                             |
|        | TRG will make deployment decision.                          |
+--------+-------------------------------------------------------------+
| 10     | Prepare OAT Report                                          |
| /01/04 |                                                             |
+--------+-------------------------------------------------------------+

**3.0 Test Recommendations and Report**[]{#__RefHeading___Toc76530967
.anchor}

During the OAT, the Test Director will prepare weekly status messages
summarizing any TTRs, operational issues and test completions. The
status messages will be distributed to the TRG and any other requested
recipients.

At the conclusion of the OAT, the TRG will review documented problems.
**If no TTRs with Impact 1 and 2 deficiencies remain open, and
workarounds have been developed and documented for deficiencies not
fixed, a recommendation will be forwarded to the CRS/VIP Software
Manager to proceed with the national deployment**. Upon completion of
the OAT, the Test Director will prepare an OAT Report, including details
of any TTRs, findings and recommendations.

[]{#__RefHeading___Toc78949160 .anchor}Attachment A - Test Trouble
Report

  ------------------------------------- -------------------- -------- ---------------
  **CRS OAT TEST TROUBLE REPORT (TTR)                                 
  TTR NO:**                                                           

  **Title/Summary:**                                                  

  **Date/Time Discovered:**             **Software Version:           
                                        CRS B10.0 / VIP               
                                        B3.1**                        

  **Originator:**                       **Attach:** pages             

  **Location:**                         **Configuration:**   Live     No. of
                                                             data?    Transmitters:
  ------------------------------------- -------------------- -------- ---------------

<table>
<colgroup>
<col style="width: 18%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 26%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 16%" />
<col style="width: 2%" />
<col style="width: 2%" />
<col style="width: 18%" />
<col style="width: 2%" />
</colgroup>
<tbody>
<tr class="odd">
<td colspan="2"><strong>Priority</strong></td>
<td rowspan="8"></td>
<td colspan="2"><strong>Impact</strong></td>
<td rowspan="3"></td>
<td colspan="2"><p><strong>Subsystem/</strong></p>
<p><strong>Component</strong></p></td>
<td rowspan="8"></td>
<td colspan="2"><strong>Frequency</strong></td>
</tr>
<tr class="even">
<td>Immediate fix</td>
<td></td>
<td>Prevent msg broadcast, <strong>NO workaround</strong></td>
<td></td>
<td>Software</td>
<td></td>
<td>Always</td>
<td></td>
</tr>
<tr class="odd">
<td>Include in next build</td>
<td></td>
<td>Prevent msg broadcast, <strong>reasonable workaround</strong></td>
<td></td>
<td>Hardware</td>
<td></td>
<td>Sometimes</td>
<td></td>
</tr>
<tr class="even">
<td>Include in future build</td>
<td></td>
<td>Degradation of broadcast</td>
<td></td>
<td></td>
<td>Documentation</td>
<td></td>
<td>Rarely</td>
<td></td>
</tr>
<tr class="odd">
<td>Requires a replacement system</td>
<td></td>
<td>Less critical – loss of minimum capability</td>
<td></td>
<td rowspan="4"></td>
<td>Installation</td>
<td></td>
<td>One-time occurrence</td>
<td></td>
</tr>
<tr class="even">
<td>Undetermined</td>
<td></td>
<td>Minimum to no impact, nice to have</td>
<td></td>
<td>Other</td>
<td></td>
<td>Always</td>
<td></td>
</tr>
<tr class="odd">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>See description</td>
<td></td>
</tr>
<tr class="even">
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td></td>
<td>Unknown</td>
<td></td>
</tr>
</tbody>
</table>

  ---------------- ------------------------- ------------------- ---------------
  **Problem        Reference ECRs/TTRs:      Test                
  Description:**                             Procedures/Steps:   

                                                                 

  **Recommended                                                  
  Solution:**                                                    

                                                                 

  **Authorizing                                                  **Date:**
  Signature:**                                                   
  ---------------- ------------------------- ------------------- ---------------

[]{#__RefHeading___Toc78949161 .anchor}Attachment B - CRS Build 10.0/VIP
Build 3.1 Release Notes

These notes document the new features and bug fixes incorporated into
CRS Build 10.0 and VIP Build 3.1 Engineering Change Request (ECR)
numbers have been provided to reference a formally documented problem
which has been resolved by this build. Refer to the CRS web page for the
latest Release Notes.

Number range CHAPTER**SOFTWARE ENHANCEMENTS**

1.  **ECR 832: [Support For Externally Generated Voice
    Messages]{.underline}** - Number range CHAPTER**THIS FEATURE WILL
    NOT BE ACTIVATED IN BUILD 10.0. IF CRS BUILD 10.0 RECEIVES AN
    EXTERNALLY GENERATED VOICE MESSAGE, AN ALERT MONITOR ERROR MESSAGE
    WILL BE GENERATED AND THE MESSAGE WILL BE DELETED. IF THIS
    CAPABILITY IS NEEDED IN THE FUTURE TO SUPPORT THE ALL HAZARDS
    COLLECTION SYSTEM, IT WILL BE ACTIVATED AT THAT TIME.** Prior to
    Build 10.0, CRS software only received weather related messages in
    ASCII text format. It processes the messages based on Message
    Attributes stored in the weather message header and system data
    stored in various database tables. These text messages are converted
    from text to speech either using the DECtalk algorithm or using the
    VIP. Prior to Build 10.0, CRS did not provide the capability for
    processing externally generated voice messages.

    Build 10.0 provides the capability to process, schedule, and
    broadcast externally generated voice messages. The CRS weather
    message header Message Attributes include a 5-character Message
    Format code used to identify the format and language of the message.
    Previously, the only Message Formats that could be properly
    processed were "T_ENG" and "T_SPA" for English and Spanish text
    respectively. The Build 10.0 software will process "V_ENG" and
    "V_SPA" for English and Spanish voice. Since these voice files will
    be passed through the DECtalk for broadcast on the transmitter in
    the same manner as manually recorded voice files, either of the
    "voice" Message Formats may be used for both English and Spanish
    externally generated voice files. However, for consistency, we
    recommend the use of "V_ENG" only for all externally generated voice
    files.

> Number range CHAPTERThe following is the format of the message name
> for the externally generated voice messages:
>
> **EV ID \<msg typ ID\> \<msg ID\>**

where \<msg typ ID\> is the internally-assigned numeric Message Type
identifier and \<msg ID\> is the internally-assigned numeric message
identifier of the subject message.

Some restrictions are required for the proper handling of the externally
generated voice files. Because the weather message header must be
extracted in its entirety, the **CTRL-F** and **CTRL-B** sequences are
**not** permitted to be imbedded in the voice file. The new voice
processing software will pass through DECtalk formatted .wav files, i.e.
10K sample .wav files. The software will also recognize and convert
using the SOX utility the more standard 16K sample .wav files.

2.  **ECR 831: [Add Special DMO Test NWRSAME Capability]{.underline}** -
    Prior to Build 10.0, CRS did not have the capability to perform the
    DMO Test NWRSAME. This special event code provides the NWS field
    offices a means of conducting exercises to practice issuing
    authentic warnings and other critical messages without disrupting
    the EAS network or turning on receiver codes used by industry and
    the general public. It may also be used as a maintenance aid to
    align and test the communications link.

    The CRS software has been modified to check for special Event Code
    "DMO". If found, CRS will ignore the normal NWRSAME generation of
    UGC codes based on the LACs in the message header. Instead, CRS will
    generate a single code of "999000\". The event code "DMO" should not
    normally be programmed into the receiver decoder, and the location
    code of "999000\" does not match any existing or future geographical
    area codes.

3.  **ECR 804: [Replacement Of FTP Transactions With
    SFTP]{.underline}** - The CRS consists of 2 MPs, 2 -4 FEPs, and a
    single VIP. CRS receives specially formatted text messages from
    AWIPS that are placed in a directory on the Master MP for
    processing. Text messages that are flagged to be transformed into
    the Speechify voices (Tom, Donna, and Javier) are sent to the VIP
    for processing. The VIP will convert the text messages to 16K sample
    .wav files. Optionally these .wav files may be directed through LDAD
    to external systems, such as Web Servers, the WR Interactive Voice
    Response (IVR) system, etc. This option also allows for the files to
    be converted via the SOX utility to mp3 files and transferred. After
    the files received from the Master MP are processed, the SOX utility
    is used to convert them 10K sample .wav files, which is the format
    required for DECtalk acceptance. The 10K sample .wav files are
    transferred back to the Master MP, where they are scheduled and
    copied to the shadow MP and FEPs for subsequent transmission.
    Control files are also passed back and forth between the Master MP
    and VIP that allow the transfer of timeout and status information.

    Prior to CRS Build 10.0/VIP 3.1, all the message transactions
    between AWIPS and Master MP, Master MP and VIP, and VIP and external
    systems were via file transfer protocol (ftp). These ftp
    transactions require the passing of the crs user password between
    systems and create security problems that are in violation of the
    DOC Computer Security Policy. Therefore, these transactions will be
    replaced with secure file transfer protocol (sftp). The sftp
    required the passing of authentication keys between the systems
    rather than a password. Because the transition from ftp to sftp in
    CRS Build 10.0 requires close coordination of this same change
    implemented in AWIPS OB4, ftp will remain as an option for
    transactions between AWIPS and the Master MP. This will allow sites
    to install either AWIPS OB4 or CRS Build 10.0 first. **LATEST AWIPS
    UPDATE: PLEASE NOTE THAT BECAUSE OF AWIPS LOADING PROBLEMS, AWIPS
    OB4 WILL NOT BE IMPLEMENTING SFTP. TRANSACTIONS FROM AWIPS TO CRS
    WILL CONTINUE TO USE FTP.** However transactions between Master MP
    and VIP and those between VIP and external systems will only be with
    sftp. For those functions, the ftp function will be removed in CRS
    Build 10.0/VIP Build 3.1.

    The MPs and VIP support openssh connections between themselves and
    AWIPS. This allows for the use of sftp, secure shell (ssh), and
    secure telnet. Authentication keys are needed to authorize these
    transfers or remote sessions. Public and private key files have been
    established on all these processors as part of the installation
    process. The VIP disk recovery procedure continues to be the
    utilization of CD imaging system to restore the disk. The recovery
    procedures will include new steps for the authorization keys.
    Generally, if the CRS application is re-installed, the authorization
    keys remain intact, and no steps to re-establish the keys are
    necessary. However, if the CRS application software is being
    re-installed as the result of an MP hard drive replacement, the keys
    will need to be re-established. Appendix C, CRS Build Installation
    Procedure, has been modified to reflect this fact.

    **Paths:** After the initial CRS Build 10.0 software is installed,
    six or seven connections are defined that support sftp transfers and
    ssh remote sessions. The six required paths are AWIPS to 0MP, AWIPS
    to 5MP, 0MP to VIP, 5MP to VIP, VIP to 0MP, and VIP to 5MP. The
    optional path is VIP to External System.

    **Key Configuration Files:** The sftp transfers and ssh sessions
    require that openssh has configuration data. Public key data must be
    in the files for all the authorized systems that will transfer data
    to the system under configuration. All the public key data used by
    the setup scripts will be in three types of files:

    1\. **Individual Public Data Key Files**: These are mathematical
    data and the public half of a pair of keys. Each key is associated
    with the private key at the originating end of the paths described
    above. These keys are in filenames with extensions of "pub".

    2\. **Authorized Key Files**: These are an aggregate of the public
    key data. These are the individual identity key pairs created for a
    unique user to identify without a password.

    3\. **Known Hosts Key Files:** These are an aggregate of the public
    key data. These are the keys used for computer to computer
    communication during the encryption process.

    A system wide file called **Known Hosts File** also exists as part
    of the system ssh configuration directory. These are the
    configuration files used directly by openssh and contain several
    keys.

    **Key Generation Scripts:** Key generation is done with the contents
    of the public and private mathematical keystring files for openssh
    encryption. The key generation for 0MP and 5MP is done when they are
    first rebooted immediately following the installation of Build 10.0.
    After its initial use, the key generation script is stored on the
    0MP in /etc/config/osdone/sshinstaller.sh. The VIP key generation is
    done in a similar manner. The scripts will not replace key files
    already generated, but will generate new and distinct files if a key
    file is absent. If new keys are generated, the key configuration
    script must be rerun on the MPs and VIP.

    **Key Configuration Script:** This is also called the fixkey script.
    This script will display a fingerprint of the public key files for
    verification and concatenate them together into their respective
    authorized key files. It will then prompt for known hosts
    fingerprints approval and add the approved host public key
    information into the known hosts key files.

    **Fingerprint:** This is a short string of hexadecimal digits in
    ASCII text string format. This check sum of a public key file that
    can confirm the correct key data is used comparing it to a stored,
    printed copy of the fingerprint sequence.

    4\. **ECR 805: [CRS And VIP Automatic Password
    Checking]{.underline}** - Prior to CRS Build 10/VIP Build 3.1, very
    little automatic password checking was performed.

> Number range CHAPTERThe following six rules for password checking have
> been added to the MP, FEP, and VIP systems for all users except root,
> switchmp, and sysadm:
>
> a\. Password must have at least 8 non-blank characters.
>
> b\. Password must contain at least two alphabetic characters.
>
> c\. Password must contain at least one number.
>
> d\. Password must have at least 3 different characters from the old
> password.
>
> e\. Password must differ from the user name, any circular shift of the
> user name, reverse order of the user name, or any reverse circular
> shift of the user name. (Please note that all CRS user accounts
> contain fewer than 8 characters. Therefore, having the user name as
> the password will fail on the restriction described above in (a.).

f\. Password must be changed at least every 90 days.

Additionally, the following four rules for password checking have been
added to the VIP system:

> Number range CHAPTERa. Password must contain at least one upper case
> alphabetic character.
>
> b\. Six of the characters may occur only once in the password.
>
> c\. In addition to the current password, the password cannot be
> changed to the 10 previous passwords. Therefore, the current password
> will not be able to be re-used for the next 11 password changes.
>
> d\. Password cannot contain vendor/manufacturer default passwords,
> words found in any dictionary (forward or backward), addresses,
> birthdays, or common character sequence.
>
> Number range CHAPTERBecause of password aging, when the operator logs
> into the CRS GUI or the KDE desktop, a pop-up dialog will display in
> the upper left-hand corner of the display advising him in how many
> days the respective password will expire. The operator must click
> **okay** to continue the login.
>
> **IMPORTANT NOTE: PASSWORDS FOR ALL USERS SHOULD BE CHANGED AT THE
> SAME TIME. THE WARNING AND EXPIRATION MESSAGES WILL ONLY BE SEEN FOR
> THOSE USERS THAT YOU LOG INTO. FOR EXAMPLE, MOST SITES DO NOT LOG IN
> AS CRS USER. THEREFORE, IF THE CRS USER PASSWORD IS GETTING CLOSE TO
> EXPIRATION OR HAS IN FACT EXPIRED, THE OPERATOR MAY NOT SEE THE
> WARNING OR EXPIRATION MESSAGE. THEREFORE, SITES SHOULD MAKE SURE THAT
> WHEN THEY SEE THE PASSWORD WARNING OR EXPIRATION MESSAGE FOR ONE USER,
> THEY CHANGE PASSWORDS FOR ALL USERS FOLLOWING THE PROCEDURES IN
> APPENDIX A OF THE DRAFT SYSTEM ADMINISTRATION MANUAL.**

5\. **ECR 807: [VIP Disk Imaging System Changed To Mondo Image
System]{.underline}** - Prior to VIP Build 3.1, the VIP operating system
and application software distribution, backup, and recovery were
performed using a DOS based package called Drive Image from PowerQuest.
This disk imaging system was difficult to generate the disk image and
very time consuming because it did not directly support the Linux ext3
file systems.

The new Mondo Image System is an open source Linux based package that
has been used previously in other NWS supported Linux systems. It boots
to Linux off a CD (Drive Image required a bootable diskette, and was
itself run from diskette) and can completely restore the VIP operating
system and application to a hard drive. It is Linux based and can more
easily handle the ext3 file systems.

6\. **ECR 808: [CRS Application Changes In MPs To Accommodate SFTP
Transactions With VIP]{.underline}** - Prior to CRS Build 10.0, CRS used
the ftp.ksh script to use the clear text crs user password for ftp
transfer to and from VIP. It also used the chg_emb_pw.ksh script during
CRS application install and when passwords were changed to prompt the
user to enter the crs user password. The chg_emb_pw script placed this
password in the ftp.ksh script and distributed the updated ftp.ksh
script to the other processors.

All references to ftp are changed to sftp. Commands will be accessed
from a dynamically created text file using functionality built into the
sftp so that the previous ftp mechanism is retained. The clear text crs
user password has been removed from the ftp.ksh script. This change also
requires the removal of the chg_emb_pw.ksh script.

7\. **ECR 809: [SFTP Flag Installation On AWIPS]{.underline}** - Prior
to CRS Build 10.0, all the message transactions between AWIPS and the
Master MP were via ftp.

Because the transition from ftp to sftp in CRS Build 10.0 requires close
coordination of this same change implemented in AWIPS OB4, ftp will
remain as an option for transactions between AWIPS and the Master MP.
This will allow sites to install either AWIPS OB4 or CRS Build 10.0
first. When sites install CRS Build 10.0, the installation instructions
will direct the installer to place a marker file in a shared directory
in the AWIPS system. The AWIPS OB4 software will look for that file to
direct it to use sftp for file transfer to CRS. Otherwise, it will
continue to use ftp.

**LATEST AWIPS UPDATE: PLEASE NOTE THAT BECAUSE OF AWIPS LOADING
PROBLEMS, AWIPS OB4 WILL NOT BE IMPLEMENTING SFTP. TRANSACTIONS FROM
AWIPS TO CRS WILL CONTINUE TO USE FTP. THEREFORE, THE MARKER FILE WILL
NOT BE INSTALLED ON AWIPS.**

8\. **ECR 811: [VIP SFTP Changes]{.underline}** - Prior to VIP Build
3.1, VIP used ftp for all message transactions to and from the CRS
Master MP and to external systems (remote ftp).

Libraries have been added to VIP to support the sftp and ssh protocols.
All transactions to and from the CRS Master MP and to external systems
(remote ftp) will now use the sftp protocol. For Master MP/VIP
transactions this includes receipt of VIP text messages, transmittal of
wave files, and receipt/transmittal of status information.

9\. **ECR 813: [CRS SFTP Wrapper]{.underline}** - Prior to CRS Build
10.0, CRS used ftp for both sending/receiving files to/from other
systems. The ftp wrapper used within CRS contains logic that at the end
of the ftp session, signals the CP_AI_RCV binary to look in the
appropriate Master MP directory for a new raw text message.

A similar sftp wrapper has been written to check in the appropriate
directory at the end of the sftp session.

10\. **ECR 815: [Expansion Of Civilian Generated Event Codes
Table]{.underline}** - CRS Build 8.5 included the capability to generate
a SAME originator code for civilian (non-NWS) generated event codes. NWS
generated event codes have an originator code of WXR. The civilian
generated event codes have an originator code of CIV. Build 8.5 defined
a new file on the MPs: /crs/data/SS/SAME_event_codes.dat with the four
civilian generated event codes: CEM, EVI, ADR, and CAE.

The Build 9.0.1 patch distributed in January 2004, added the following
16 additional event codes to the event code table: AVA, AVW, CDW, EQW,
FRW, HMW, LEW, LAE, TOE, NUW, RHW, SPW, VOW, NIC, NPT, and NMN.

Since Build 9.0.1 was implemented as a patch, this write-up is being
included in the Build 10.0 Release Notes to ensure that the updated
/crs/data/SS/SAME_event_codes.dat file is being included in the
ClearCase software build procedure.

**BUG FIXES**

1.  **ECR 833: [Date Time/AWIPS Time Updates Stop/Start Message
    Processing Software]{.underline}** - Date/Time updates and AWIPS
    time request updates generated by the CRS operator from the CRS
    Maintenance menu will always stop the CP_VC process, which is
    responsible for all VIP message processing, which will cause the VIP
    icon in the status window to go down briefly. This is necessary
    since CRS system time updates will affect the processing of incoming
    message effective/expiration time processing. However, the automatic
    stopping and subsequent starting of the VIP message processing
    process may prove to be confusing to the operator.

    The Date/Time Update window has been modified to add the following
    Information Dialog when the operator initiates a time change
    request:

    **Update time will restart VIP interface stop/start cp_vc**

    The operator will be given the opportunity to continue with the
    command or cancel it.

2.  **ECR 834: [Multiple Future Effective Time Watch/Warning Interrupts
    Not Scheduled]{.underline}** - Prior to CRS Build 10.0, multiple
    watch/warning interrupts with effective times in the future were not
    scheduled. For example, suppose the current time was 2200 and a
    severe thunderstorm warning (WBCSVRWBC) was received with an
    effective time of 2210. Then another severe thunderstorm warning
    (WBCSVRWBC) was received before 2210 with an effective time of 2220.
    Normally, the second message should replace the first message.
    However, in this operationally esoteric case, neither the first nor
    second message would ever play.

    The CRS software has been modified to handle this operational
    situation in a more reasonable manner. In the example described
    above, the first message would not play when its effective time was
    reached. Instead, because its effective time was in the future when
    it was received, it will be permanently replaced by the second
    message, thereby ensuring that it will never play. The second
    message will play when its effective time is reached.

3.  **ECR 835: [MMI Display's Font Is Too Small]{.underline}** - Prior
    to CRS Build 10.0, the font used for the Message Monitor (MMI
    display) was Helvetica 7. Middle Aged eyes found this very difficult
    to read. The font has been changed to Helvetica 10.

4.  **ECR 836: [CRS/ROAMS Interface Software Does Not Recognize Local
    10-Digit Dialing Bit]{.underline}** - Prior to CRS Build 10.0, the
    CRS/ROAMS interface software in CRS did not recognize the bit used
    to define local 10-digit dialing. Therefore, the display resulting
    from a Query to a ROAMS set for 10-digit dialing would include a
    garbled area code in the telephone number. For example, a site using
    10-digit dialing with an area code of 785 would display an area code
    of 7185 after the Query.

    The CRS software has been modified to check if the area code is
    overflowed as a result of the 10-digit dialing. If it is overflowed,
    it will offset the area code to adjust the display properly.

5.  **ECR 786: [VIP Processing/Manual Recording
    Collision]{.underline}** - Prior to CRS Build 10.0, it was possible
    to encounter problems while simultaneously manually recording a
    Weather Message (either Weather Message record or Emergency
    Override) and processing a VIP message. This could result in the
    stopping/starting of CRS. If database problems existed, CRS may not
    start successfully, which would require operator intervention to
    clean up the database. As a result, we recommended that sites
    separate the manual record function from the VIP processing
    function, i.e. make sure that all manual recordings are made on ACP2
    (Shadow Console).

    To distribute both digitized voice (manual voice recordings) and VIP
    wave files in a manner that alleviates the collision problems, the
    stream copy client/server logic was rewritten to support two stream
    copy processes. One supports digitized voice messages, the other
    supports VIP wave files. The new logic facilitates the stopping of
    all processing of any VIP message that is being stream copied while
    a digitized voice message is being distributed.

6.  **ECR 806: [VIP OS Security Patches]{.underline}** - When the Harris
    Scan software was performed on the VIP Red Hat Linux Version 7.3, it
    detected four security deficiencies for which patches exist but had
    not been installed. These four security patches and all production
    patch packages available from Red Hat, Red Hat Legacy, and the NOAA
    NCIRT patch server through May 3, 2004 have been applied to VIP
    Build 3.1.

7.  **ECR 810: [Messages With Duplicate LACs Are Not
    Scheduled]{.underline}** - Prior to CRS Build 10.0, messages
    containing duplicate Listening Area Codes (LACs) in the Message
    Attribute Header would result in its failure to be scheduled.
    Additionally, it would result in the generation of a log entry from
    CP_VC concerning DB_MH notification failing, this error message did
    not go to the Alert Monitor. Therefore, the operator would be left
    with a situation where a message was not being scheduled, but no
    operator notification that would indicate what the problem might be.

    The CRS Build 10.0 software includes a new function that performs a
    duplicate check that is used within the LAC parser. This check will
    allow the parser to "skip over" duplicate LACs and process the
    message normally.

    In the course of testing this change, we discovered that the changed
    exacerbated an existing, but never before detected problem. If a
    message incorrectly separates multiple LACs, i.e. using a ","
    instead of "-", the new function will cause the software to enter
    into an infinite loop. This problem has been fixed so the software
    will properly detect the illegal delimiter.

8.  **ECR 812: [Remote FTP Script Changes]{.underline}** - Prior to VIP
    Build 3.1, sometimes the VIPserver would not finish the conversion
    before the ftp put function called in the remote ftp of MP3 files.
    Also, the pre-defined length of the remote ftp string (remote
    username:hostname:password) was not always long enough to support
    what had to be entered.

    The remote ftp script has been modified to insert a 10-second delay
    in the script for the remote ftp of MP3 files. The 23 character
    string limitation has been increased to 32.

9.  **ECR 816: [Remove Spurious Messages From The MMI]{.underline}** -
    Prior to CRS Build 10.0, a number of error messages routinely
    displayed in the MMI, which caused questions and confusion. These
    errors include the following:

    a\. **System not licensed or unregistered software.**

    b\. **Multi-line sendmail errors (unqualified hostname 0mp unknown)
    with retries.**

    CRS Build 10.0 removes both **a** and **b**.

10. **ECR 819: [Multiple Sets of VIPserver Processes May
    Run]{.underline}** - It is possible for the VIP GUI to stop running,
    even though the VIPserver processes continue to run. In this case,
    even though the operator cannot access the VIP control windows, the
    VIP icon in the CRS Status window is up and VIP messages continue to
    be processed. The problem is that the natural reaction to this
    situation is for the operator to restart the GUI. After the GUI is
    up and operating, the main GUI menu will indicate that VIP is down,
    **even though it is not.** Therefore, the natural reaction of the
    operator is to restart the VIP application. Now the VIP menu will
    indicate that VIP is up, and the operator will assume all is O.K.
    Prior to VIP 3.1, when the operator restarted the VIP application
    under these circumstances, he was actually starting a second set of
    VIPserver processes. **When more than one set of VIPserver processes
    are running, the results of the VIP conversion may be disastrous.**
    Both sets of VIPserver processes are processing the same message and
    the results are unpredictable. The converted wave file may have long
    gaps of silence or may play much too fast.

    Modifications in VIP Build 3.1 have been made that kill all the old
    VIPserver processes when the VIP application is restarted. This
    prevents the multiple VIPserver scenario described above.

11. **ECR 821: [SOM Changes]{.underline}** - The Operational Build 9.0
    version of the CRS Site Operator's Manual (SOM) is missing the
    Create ASCII file button on all figures depicting the XCRS_Site
    Configuration Developer screen. Also, Section 3.6.2.5.13 of the SOM,
    Off-Line Tone Generator, does not have language specifically
    instructing the user to close the Transmitter Configure window
    following the disabling of the transmitter and prior to entering the
    Off-Line Tone Generator window.

    The Operational Build 10.0 version of the SOM has been changed to
    include modified Figures 141 - 144 to depict the additional button
    and the language to exit the Transmitter Configure window in the
    appropriate part of Section 3.6.2.5.13. These changes have also been
    included in the on-line Hyper Text Help pages.

12. **ECR 823: [Some Site Identifiers Are Incorrect in the
    VIP]{.underline}** - Prior to VIP Build 3.1, the VIP file
    WFOsites.env had several incorrect entries. This file contains the
    list of approved sites during delivery of new VIP software. Only
    site identifiers in this list may be entered during VIP software
    setup via the Setup Wizard. Once the site identifier is selected, it
    is written to the version file on the VIP. This file is used during
    the configuration of the remote ftp. Therefore, an incorrect sited
    identifier in the WFOsites.env file will contaminate the remote ftp
    configuration.

    The following lists each site, the old identifier, and the new
    identifier in VIP Build 3.1:

    *Site Old ID New ID*

    **Jacksonville, FL KJAN KJAX**

    **Key West, FL KEYN KEYW**

    **NMTW (Alpha) NMTW NMTW\***

    **NMDW NMDW NWSHQ2\***

    Also, neither the CRS nor VIP Site Identifier file contained the
    identifiers for the 3 NRC systems. Therefore, CRS Build 10.0 and VIP
    Build 3.1 will modify the respective files to include the 3 NRC
    identifiers as follows:

    *Site Old ID New ID*

    **NRC System 1 NRC1**

    **NRC System 2 NRC2**

    **NRC System 3 NRC3**

Number range CHAPTER13. **TTR 803: [Off-Line Tone Generator Failure To
Write Configuration To Disk]{.underline}** - Prior to Build 10.0, the
CRS Off-Line Tone Generator software did not write changes to tone
amplitude to the transmitter configuration file stored on the MP hard
drive. The changes were correctly made in memory, resulting in the tones
being generated with newly modified amplitude. However, at some later
point in time when the CRS application was terminated and then
restarted, the tone amplitude written into memory from the configuration
file was the old values. Therefore, from that point on the tones would
be generated with the old and incorrect values. This required a work
around in the transmitter alignment procedures to have the user enter
the Transmitter Configure window to save the values (including the tone
amplitudes), since changes in this window were correctly written to the
transmitter configuration file.

> CRS Build 10.0 has been corrected to write the tone amplitude changes
> to the transmitter configuration file.

14\. Number range CHAPTER**TTR 852: [The Save As Function Does Not Work
For Listening Areas and Listening Zones]{.underline}** - The CRS GUI
includes a *File* menu that allows users to access 5 submenu options.
The *Save As* option allows the operator to save the current record
under a new name, thereby maintaining the integrity of the originally
retrieved record. This option may prove useful in creating new records.
For instance, this option could be used in the creation of multiple new
Message Types that are very similar. Once all the parameters for the
first Message Type are entered and saved, it can be used as a template
for the others with the *Save As* option. From most of the GUI windows,
the *Save As* option will cause a pop-up window to display with a prompt
for a new name that is of variable length. However, prior to Build 10.0,
for Listening Areas and Zones, the *Save As* option prompts for a name
that is erroneously restricted to 5 characters, rather than 6. This
erroneous restriction, therefore, makes it impossible to use the *Save
As* function for Listening Areas and Zones.

> The problem is corrected in Build 10.0 by eliminating an incorrect
> decrement of the maximum length field.

Number range CHAPTER

15\. **TTR 856: [Message Record/Playback Dialog Help
Problems]{.underline}** - Clicking on the Help button while in any CRS
window forces the Netscape Communicator to display the SOM documentation
for that window. Prior to Build 10.0, however, the display for the
Weather Message Record/Playback dialog window resulted in the display of
an error window which detailed a lock file error in Netscape. Moreover,
another Netscape

> was displayed that listed all the Help files. Upon clicking on the
> error window OK button, the Record/Playback dialog help window was
> displayed. Additionally, clicking on the Help button in the Weather
> Message Text Message Playback dialog window resulted in the display of
> the Weather Message Correction documentation.
>
> These problems have been fixed in Build 10.0 so the proper
> documentation is initially displayed.

16\. **TTR 854: [Print Jobs Cannot Be Removed From Print
Queue]{.underline}** - The CRS Print Monitor can be invoked from the CRS
Utilities menu. Upon doing so, the Print Monitor window will be
presented. The currently configured printer and status will be displayed
as part of the window title. From this window, the operator may access,
select, and submit a job to the printer. Several print management
functions also are available to the operator including the ability to
remove a job from the print queue via the Remove Job button. However,
prior to CRS Build 10.0, pressing this button did not properly remove
the print job from the queue.

> This problem has been fixed in Build 10.0 so print jobs can be removed
> from the queue.

[]{#Generated_Bookmark33 .anchor}

Attachment C - CRS Build 10.0/VIP Build 3.1 OAT Questionnaire

(To be completed by the site CRS Focal Points at the end of OAT,
coordinating responses with the test site management and staff).

Test Site:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Date: \_\_\_\_\_\_\_\_\_\_\_\_\_

Name and Title:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Beginning and Ending Dates of Test:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

Respond to the statements below by checking the rating box that best
describes your opinion according to the following code:

+---------+------------+-----------+-------------+------------+------+
| **1**   | **2**      | **3**     | **4**       | **5**      | *    |
|         |            |           |             |            | *[N/ |
| **[Exc  | **         | **[       | **[De       | **         | A]{. |
| ellent] | [Good]{.un | Satisfact | ficient]{.u | [Unsatisfa | unde |
| {.under | derline}** | ory]{.und | nderline}** | ctory]{.un | rlin |
| line}** |            | erline}** |             | derline}** | e}** |
|         | Performed  |           | Performed   |            |      |
| Pe      | well, met  | Performed | in          | Performed  | **   |
| rformed | field      | in a      | uns         | in a       | Does |
| in a    | needs and  | manner    | atisfactory | wholly     | Not  |
| manner  | offered    | that      | manner,     | unsa       | App  |
| that    | some       | meets     | does not    | tisfactory | ly** |
| could   | im         | basic     | fully meet  | manner,    |      |
| not be  | provements | field     | field       | does not   |      |
| i       |            | needs     | needs, may  | meet field |      |
| mproved |            |           | be          | needs and  |      |
|         |            |           | workarounds | negatively |      |
|         |            |           |             | impacts    |      |
|         |            |           |             | field      |      |
|         |            |           |             | operations |      |
+=========+============+===========+=============+============+======+
+---------+------------+-----------+-------------+------------+------+

List formatters used:
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

  ------------------------------------------------------------------------------------------------
  **Statement**                                  **1**   **2**   **3**   **4**   **5**   **N/A**
  ---------------------------------------------- ------- ------- ------- ------- ------- ---------
  CRS ingest of AWIPS products using listed                                              
  formatter(s).                                                                          

  Installation of CRS Build 10.0 software                                                
  (*including password setting and accuracy of                                           
  installation notes*).                                                                  

  Installation of VIP Build 3.1 software                                                 
  (*including accuracy of installation notes*).                                          

  Installation of CRS/VIP ssh keys (*including                                           
  accuracy of installation notes*).                                                      

  CRS ability to successfully send products to                                           
  NWR transmitters.                                                                      

  NWR transmitters successfully transmitted CRS                                          
  products.                                                                              

  The quality of the CRS Build 10.0/VIP Build                                            
  3.1 audio.                                                                             

  CRS Build 10.0 automatic password checking                                             

  VIP Build 3.1 automatic password checking                                              

  VIP remote sftp implementation, including any                                          
  additional support for functional continuity                                           
  (*only for sites performing VIP remote file                                            
  transfers*)                                                                            

  CRS operations with NWRSAME tones, including                                           
  DMO test event code.                                                                   

  The CRS Build 10.0/VIP Build 3.1 operators or                                          
  forecasters workload.                                                                  

  The CRS Build 10.0/VIP Build 3.1 maintenance                                           
  workload.                                                                              

  CRS Build 10.0/VIP Build 3.1 operations under                                          
  non-severe weather conditions.                                                         

  CRS Build 10.0/VIP Build 3.1 operations under                                          
  severe weather conditions.                                                             

  Overall, CRS Build 10.0/VIP Build 3.1 is                                               
  suitable for general implementation.                                                   
  ------------------------------------------------------------------------------------------------

Please comment on any item that received **[a rating of 4 or
5.]{.underline}** Include any comments received concerning maintenance.
You may provide other comments, as desired*.*

[]{#__RefHeading___Toc78949163 .anchor}Attachment D - CRS Build 10.0/VIP
Build 3.1 OAT Test Site Introduction Agenda

+---+--------------------------------------------+---------------------+
| 1 | Introduction of test team                  | Test Coordinator    |
| \ |                                            |                     |
| . |                                            |                     |
+---+--------------------------------------------+---------------------+
| 2 | The Test Structure                         | Test Coordinator    |
| \ |                                            |                     |
| . | \- Overview of CRS Build 10.0/VIP Build    |                     |
|   | 3.1                                        |                     |
|   |                                            |                     |
|   | \- Test schedule                           |                     |
+---+--------------------------------------------+---------------------+
| 3 | Test Team Responsibilities                 | Test Coordinator    |
| \ |                                            |                     |
| . | \- Hours working on-site                   |                     |
|   |                                            |                     |
|   | > \- Activities                            |                     |
+---+--------------------------------------------+---------------------+
| 4 | Site Management and Staff Responsibilities | Test                |
| \ |                                            | Coordinator/MIC     |
| . | \- ESA Responsibilities                    |                     |
|   |                                            |                     |
|   | \- CRS Focal Point Responsibilities        |                     |
|   |                                            |                     |
|   | \- Forecaster/HMT responsibilities         |                     |
|   |                                            |                     |
|   | \- Reporting/documenting problems          |                     |
+---+--------------------------------------------+---------------------+
| 5 | Test Team Office Needs                     | Test Coordinator    |
| \ |                                            |                     |
| . | > E-mail, PC with Internet connection,     |                     |
|   | > modem phone lines, copying, phones, work |                     |
|   | > space, etc.                              |                     |
+---+--------------------------------------------+---------------------+
| 6 | Other Expected Visitors                    | Test Coordinator    |
| \ |                                            |                     |
| . |                                            |                     |
+---+--------------------------------------------+---------------------+
| 7 | Discussion of Questions and Concerns       | Site Management     |
| \ |                                            |                     |
| . |                                            |                     |
+---+--------------------------------------------+---------------------+

[]{#__RefHeading___Toc78949164 .anchor}Attachment E - Example VIP Remote
SFTP Key Installation and Network Setup

**All VIP remote sftp users must convert to a standard configuration
which is supported by CRS Build 10.0/VIP Build 3.1. The VIP Build 3.1
software requires OAT sites to transfer VIP messages from VIP to the
LDAD Server (LS1). These messages will then either be transferred to an
external system or an external system will retrieve the messages from
the LS1. The transfer or retrieval of VIP WAV or MP3 files will be an
OAT site designated method and the setup and configuration will be
performed by OAT site personnel.**

Users of the VIP remote sftp (formerly remote ftp) capability must copy
the **[vip.pub]{.underline}** key from the VIP to a keyfile diskette.

The operator should coordinate this step with the System Administrator
of the LS1.

1.  Create a **crs** user account on the LS1.

2.  Log on the LS1 as **crs**. Insert the keyfile diskette in a: drive.

3.  Verify **/home/crs/.ssh** directory exist with protection of
    **700**.

4.  If the directory does not exist, then create one and copy the key
    file by

> **mkdir /home/crs/.ssh**
>
> **chmod 700 /home/crs/.ssh**
>
> **mcopy a:vip.pub /home/crs/.ssh/authorized_keys**
>
> Go to Step 7.

5.  If the directory exists, then check to see authorized_keys file
    exists.

6.  If authorized_keys file does not exist, then copy vip.pub by

> **mcopy a:vip.pub /home/crs/.ssh/authorized_keys**
>
> If authorized_keys file exists, remove and create new authorized_keys
> file by
>
> **rm /home/crs/.ssh/authorized_keys**
>
> **mcopy a:vip.pub /home/crs/.ssh/authorized_keys**

7.  Create an entry for the LDAD server in the VIP routing table:

> Click the **KDE Gear**
>
> Click **System**
>
> Click **Network Configuration**
>
> Select **Active etho device**
>
> Click **Edit**
>
> Click on **route** tab and click on **add**
>
> Specify [LS1 IP address]{.underline} as Address, subnet mask of
> [255.255.255.255]{.underline} and the **gateway IP address**.

8.  Restart the network by **Service network restart**

9.  Additionally, the operator must approve the remote fingerprint of
    the target system.

> **su crs**
>
> **sftp xxx.xxx.xxx.xxxx** where xxx=LDAD server IP address

Logons and transfers into VIP from outside of CRS are not authorized to
be added to the VIP computer. Likewise, outside generated public keys
are **NOT** to be added to the VIP computer.

Additionally, the OAT site personnel must approve the remote fingerprint
of the remote external system. **To accomplish this fingerprint
approval, the OAT site personnel operator (as a VIP "crs" user) must
perform, from VIP, a manual sftp of a test file to the remote system.**
The OAT site personnel will be prompted to approve the remote
fingerprint of the target system. Logons and transfers into VIP, from
outside of CRS, are not authorized to be performed on the VIP computer.
**Public key files NOT generated and copied during the CRS Build
10.0/VIP Build 3.1 software installations are NOT to be added to the CRS
and VIP computer**.