Must [Application] Software Requirements Specification

AVHRR Acquisition System 
Software Requirements Specification

 
Prepared by:  Dave Lloyd, Tim Baltzer 
  Software Engineer, 
  Raytheon, ITSS
Concurred by:  Tim Beckmann 
  Software Project Lead, 
  Raytheon, ITSS
Approved by:  Mike Benson 
  Project Manager, 
  Raytheon, ITSS
 
Document History
 
 
 
Number Date and Sections Notes
1 Feb 2001 Initial Development
2 Feb 21, 2001 Add comments from peer review
3 July, 22 2002 Deleted several requirement that were no longer needed or deemed unfeasible.
4    
5    
6    
 

Contents

INTRODUCTION

Identification

The AVHRR live acquisition system consisting of the new model 225W software implemented frame synchronizer,  the new Intel based Linux server, and the existing components (receiver, bit synchronizers, and ACU).

System Overview

The purpose of this system upgrade is to replace the frame synchronizer with a software implemented frame synchronizer, replace the VAX3900 with a Linux server, replace the NBS timeclock with NTP, eliminate the custom interfaces and bus converters, and to replace the software running under VMS with software running under Linux.  The sponsor of this system upgrade is Mike Benson, the Production Services Manager at EDC.   This software implementation will be limited to the Linux Server as outlined in Figure 1.  All other systems and connections are pre-existing.


 

                                 Figure 1 - AVHRR Acquisition System Diagram

Document Overview

The purpose of this document is to establish the requirements for the entire AVHRR Acquisition System.

REFERENCED DOCUMENTS

Applicable Documents

- Model 225W Frame Synchronizer Operation Manual
- LAS Programmer's Manual
- NOAA KLM User's Guide

Reference Documents

- KLM User's Guide
- NOAA Polar Orbiter Data User's Guide
- The existing ACQUMAN/INHALE source code

REQUIREMENTS

  1. Interface Requirements
    1. Shall have an interface with the receiver.
      1. Shall be a serial port.
      2. Must control the receiver.
    2. Shall be able to interface with the frame synchronizer multicast port.
      1. Shall have a direct ethernet connection, refer to the Frame Synchronizer Manual
      2. Communication shall be via a User Datagram Protocol (UDP).
    3. Shall be able to interface with the frame synchronizer unicast port.
      1. Shall have a direct ethernet connection, refer to the Frame Synchronizer Manual
      2. Communication shall be via a TCP/IP protocol.

  2. Input Requirements
    1. The AVHRR master schedule will exist in the ADAPSTABLES directory on the acquisition  system.  This input file is a local copy of the master schedule residing on the ADAPS production system and is updated by the ADAPS production system whenever Data Management personnel performs scheduling activities. The format of the AVHRR master schedule is as follows:


  • The system time.  The system time must be within 1 millisecond of NBS (National Bureau of Standards) time.

  • Output Requirements
    1. Raw acquisition image with a 512-byte header
      1. Minimum requirements for the 512-byte header:
        1. Deleted.
        2. The contents of the header is irrelevant.
      2. This raw acquisition image will be moved from the ADAPSACQ directory on the acquisition system to the ADAPSACQ directory on the ADAPS production system.
      3. The remainder of the raw acquisition is merely a reflection of what is acquired by the satellite dish.
      4. The format of this image must be the 16-character sceneid, all lower case, with an "sf2" suffix. The "sf2" denotes that this is a local Sioux Falls acquisition in big-endian format.
    2. Output display.  The display shall be cleared prior to displaying an acquisition. An image shall be displayed on a monitor as it is being acquired in a 'moving window' manner.
      1. Shall always be displayed in a north-up orientation.
      2. Shall display a band combination which exhibits image features such as coastlines, clouds, etc. (for both day and night passes). Example:
        1. band 2 (red), band 1 (green), band 1 (blue) for day passes
        2. band 4 (red), band 3 (green), band 3 (blue) for night passes
        Note: For NOAA-KLM series satellites the band selection has not yet been fully determined. The initial recommendations are 211 (RGB)for day-time passes and 455 (RGB) for night time passes.
      3. Upon completion of an acquisition, must display the next scheduled acquisition time (in local time).
      4. Display image as it is acquired with a maximum lag time of 5 seconds.
      5. Display image with a resolution of at least 512 x 512 pixels.
    3. Generate a master schedule update file (to update the production master schedule file when a scene has been acquired or missed).
      1. The contents of this file must be in the following format:
        "ah16021501125434 -15 S 00 - -    - -"
        "123456789012345678901234567890123456" (this line is not part of the file, only here to show spacing)
        where:
        1. ah16021501125434 is the 16-character scene identifier.
        2. 'S' is the status flag whose value must be:
          a) 'M': The scene has been missed
          b) 'D': The scene has been acquired and copied to disk
        3. All other fields within this file must be maintained for historical purposes only.
      2. The name of this file must be as follows: "modsid_DDMMYYHHMMSS.sch" where DDMMYYHHMMSS is a unique time stamp (2 character day-month-year-hour-minute-second).
      3. This file shall be moved from the ADAPSTABLES directory on the ADAPS acquisition system to the ADAPSTABLES directory on the ADAPS production system.
    4. Deleted.
    5. Output a time correction value for each acquired image.  This time correction value represents the millisecond difference between the satellite and system time (satellite  time - system time).  This information must be  appended to the appropriate time correction file ('noaa16.timcor', for example) in the $ADAPSTABLES directory on the ADAPS production system.
    6. If the ADAPS production system is not available, the imagery and time correction data shall reside on the acquisition system until such time that the production system is available. The transmission of this data shall be attempted at intervals of 10 minutes or less, until successful.

  • Functional Requirements
    1. Shall have the ability to read the AVHRR master schedule and determine the next pending scene. The AVHRR master schedule will be in time sequence order.
    2. Shall be able to communicate with the receiver to change the frequency of the receiver.
      1. Open the communications port
      2. Send the port two 'blank spaces'
      3. Send the port the string "XN" where N is
        1. '1' for NOAA-09  (N/A)
        2. '2' for NOAA-10  (N/A)
        3. '3' for NOAA-11  (N/A)
        4. '2' for NOAA-12  (1698.0 MHz)
        5. '5' for NOAA-14  (1707.0 MHz)
        6. '2' for NOAA-15  (1698.0 MHz)
        7. '5' for NOAA-16  (1707.0 MHz)
    3. Shall be able to communicate with the frame synchronizer with status and command strings via unicast port. Refer to the "Model 225W Frame Synchronizer Operation Manual" for specific details.
    4. Deleted.
    5. Shall be able to start the acquisition of an image at the scheduled start time. Shall be able to stop the acquisition of an image at the scheduled stop time. The start and stop times are specified within the AVHRR master schedule.

  • Performance Requirements
    1. Shall be able to ingest data from the frame synchronizer at a minimum of 133k bytes/second.
    2.  

  • Operational Requirements
    1. Shall write log files to maintain a history of errors and processing messages.  In order for the ADAPS MONITOR to monitor this process, the log files must be 'touched' (access time updated) at least every 10 minutes. These log files are general in nature, there are no specific format requirements.
    2. The following errors shall be reported:
      1. Bit sync lost lock
      2. Frame sync lost lock
      3. Frame sync bit slip
      4. Frame sync pattern errors
    3. Shall run the acquisition system from 'init scripts' so that it will automatically start during a system boot.
    4. Must be able to acquire at minimum satellites NOAA-12 through NOAA-17.

  • Other Requirements


  • TEST CASES

    Test Number Requirement Numbers  Description
    1a 1.1, 1.2, 1.3, 1.4, 
    4.1, 4.2, 4.3, 4.4, 2.1
    Schedule a NOAA-12 acquisition, followed by a NOAA-16 acquisition (these are downloaded at different frequencies).  Ensure that the frame synchronizer is set to the appropriate data type.  Also ensure that the raw acquisition from the 'old' system and the 'new' system are the same except for the header (for both images).  If the data is correctly downloaded, the receiver has successfully switched frequencies, the frame synchronizer is set to the proper data type, and the data was received from the mulitcast port.
    1b 3.1, 4.5 After test 1a has successfully completed, ensure that the acquisition image has been successfully transferred to the ADAPSACQ directory on the ADAPS production system.   This test will be run concurrently with the legacy acquisition system and the output images compared.  The image contains the 512-byte header with minimum required data, all other contents will be the same as the reference image. 
    1c 3.2, 4.1 During test 1a, the image is displayed in a north-up manner.  To complete this test, both an ascending and descending scene must be successfully displayed.  Verify that the 'next' scene is correctly displayed on the monitor following the acquisition.
    1d 3.3, 3.4 The 'modsid' file is moved to the ADAPS production system into the appropriate directory (ADAPSTABLES).  The local AVHRR master schedule is appropriately updated to reflect that the scene was acquired or missed.
    1e 3.5 Verify that the time correction table on the ADAPS production system has been updated to include the acquired images time correction value (in the ADAPSTABLES directory).
    1f 6.1 Verify that the appropriate log files have been written to.
    Delete 2 Delete Delete
    3 2.2 Ensure that NTP and precision timekeeping is installed and activated on the acquisition system.
    4 5.1 Time an acquisition (end time - start time), and divide the number of bytes acquired during that timeframe to ensure the overall transmission rate is at least that defined in 5.1.
    5 3.2d By observation, verify that the time of acquisition and time of display do not exceed that defined in requirement 3.2d.
    6 6.2 Reboot the system and verify that the acquisition system has automatically restarted.
    7 3.5 Verify the time code correction through comparison to the legacy system and through viewing the image with linework applied.
     

    REQUIREMENTS TRACEABILITY

    Requirement Number Test Number Design Code
    1.1 1a    
    1.2 1a    
    1.3 1a    
    1.4 1a    
    2.1 1a    
    2.2 3    
    3.1 1b    
    3.2 1c    
    3.2d 5    
    3.3 1d    
    3.4 1d    
    3.5 1e, 7    
    4.1 1a, 1c    
    4.2 1a    
    4.3 1a    
    4.4 1a    
    4.5 1b    
    5.1 4    
    6.1 1f    
    6.2 6    
     

    NOTES

    [ADDITIONAL DATA]

    ACRONYMS
     
     
     
    Acronym Description
    ADAPS AVHRR Data Acquisition and Processing System
    AVHRR Advanced Very High Resolution Radiometer
    EDC EROS Data Center
    EROS Earth Remote Observation Systems
    LAS Land Analysis System
    NBS National Bureau of Standards
    NOAA National Oceanic and Atmospheric Administration 
    NTP Network Time Protocol