Unisys Channel Data Specification and Content

NOAAPORT Unisys Channel
Data Specifications and Content
December 2001

Data Specifications

The Unisys Channel is available to provide data in a NOAAPORT format that is not currently available on the standard NOAAPORT channels. The content is a variety of legacy data, commercially available data and value added products. Because of the proprietary nature, the data on the channel is encypted and compressed. In order to access the data, a decryption program and key files will be provided.

Data Encryption and Compression

The encryption uses a public domain encyption API and the ZLIB deflate/gzip for compression. This requires a slightly different structure to the data content. The NOAAPORT CCB (header) is the same. The WMO header is developed to mimic WMO standards so data can be classified using existing WMO categories even though any WMO header could be used. The originating location will be ZUNI to denote Unisys as the source. Every product will have an AWIPS header that describes more closely the data content. These headers will be described in more detail below in the Data Content section. In addition, there will always be a Unisys header following the AWIPS header. This header describes the type of data, the encryption key name and compression type (if used). Here is an example header:

DFAA91 ZUNI 040334
454FAA
UNISYS=V1.0 TYPE=FOS KEY=FOS6041A COMP=GZIP PAD=!!!!!!!

This example is for FAA 604 data. The data type is "FOS". The encryption key name is "FOS6041A" and the data is GZIP compressed. There will be a different key name for each type of data on the channel. This gives Unisys the ability to control access to each data type. So individual data types can be turned on and off at any time by changing parameters in the encryption key file (see below). The PAD is for word alignment for encryption.

Encryption Key Files

This file contains a mapping between data key names and encryption key values. The values are fed into the encryption API to decrypt the data. The filename will always be "mykeybox.inf". Here is a sample key file:

CRYPTOKEY=NatMos1B CRYPTOVALUE=NONE
CRYPTOKEY=NatMos1A CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1B CRYPTOVALUE=NONE
CRYPTOKEY=RegMos1A CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1B CRYPTOVALUE=NONE
CRYPTOKEY=DIFAX1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSPPS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSDDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1B CRYPTOVALUE=NONE
CRYPTOKEY=FOSIDS1A CRYPTOVALUE=NONE
CRYPTOKEY=FOS6041B CRYPTOVALUE=6CQ5S9jT8tTr9TwJC5i2Dfne
CRYPTOKEY=FOS6041A CRYPTOVALUE=wyyfekmM7rE4MQqW9YBk4osA

Each type of data (such as FOS604) on the channel will have a specific key and decryption value. For each data type, there will be two keys: an A and a B key (FOS604A and FOS604B). At any time, one of the two is active but at a predetermined time, the key will change. For example, if the current active key is A, the A key will be used. This is determined by the "KEY=" tag in the Unisys header. If the key changeover is set for 00Z, at that time, the key will be B, rather than A. The key file contains both so that there is no interruption in data if a new key file is not received prior to the changeover. After the changeover time, a new key file will be sent with the current B key and a new A key that will be used after the next changeover.

The key files will be sent 3 times during the afternoon to make sure the enduser receives it. They will be sent at roughly hour intervals between 19 and 22Z. The key files are themselves encrypted and keys must be used to decrypyt these. Here is a header from a key file:

NLIC99 ZUNI 022100
KUNI03
UNISYS=V1.0 TYPE=KEY KEY=UNISYS3 COMP=NONE PAD=!!!!!!!!

The end user will be provided with a key name specific to the customer and value to decrypt this file. Once decrypted, the file will be written to "mykeybox.inf" and can be used to decrypt the other data types.

Product Manager Setup and decode Program

To decrypt and decompress the data, there are two steps. First is to decrypt the key file and the second is to decrypt the data. Here are examples using the WXP product manager:

#
# Key files
#
NLIC99            B|  /usr/prodman/bin/decode -k /usr/prodman/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
#
# FOS/FAA 604 products
#
DFAA91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/faa604/%y%m%d%h%n.faa
DDDS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.dds
DPPS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.pps
DIDS91            B|  /usr/prodman/bin/decode -f /usr/prodman/unisys/lic - %D/fos/%y%m%d%h%n.ids

The NLIC99 line takes the products with a NLIC99 WMO header and pipes the output through the decode program and outputs the "mykeybox.inf" file. Since there are multiple customers using the channel, each customer will be issued a key name. In this case, it is "UNISYS3". There will be more than one NLIC99 product that comes across (one for each customer) and the decode program will use only the product that has a key equal to UNISYS3 and will ignore all others. The "-k" option tells the decode program that this is a key file. The additional parameters include the directory to save the key file, the key name for the customer and the key value used to decrypt the file. The "-" parameter is for addition file output and is ignored.

Once the key file is saved to disk, it can be used to decrypt other products on the channel. Obviously each product will have to be piped through the decode program. The "-f" parameter to decode tells the program to file the product. The additional parameters determine the location of the key file, the input file name ("-" is standard input) and output filename. In these cases, the product manager constructs the output filename from the tags/wildcards. This will vary depending on the product manager.

The process for decrypting goes as follows:

The data for the product type is received and is sent to the decode program.
The Unisys header is read and the product key name is found.
The product key name is searched for in the key file and the key value is obtained
The key value is used to decrypt the data in the product
If the Unisys header specifies the data is compressed, the decode program will then decompress the data
The output is saved to the file name listed.

LDM Setup

If the product manager is the LDM, then the procedure is very similar to the procedure listed above. The only difference is that the "decode" program must be obtained for the particular platform the LDM resides on. This could be Linux, Solaris, Intel Solaris, etc. Check with Unisys to see if your platform is supported. Here is a sample "pqact.conf" entry

#  Key files
WMO     ^NLIC99 
        PIPE    -close /home/ldm/bin/decode -k /home/ldm/unisys/lic UNISYS3 120101UNISYS3KEYTEST -
#  FOS data
WMO     ^DFAA91 .... ([0-3][0-9])([0-2][0-9])([0-5][0-9])
        PIPE    -close /home/ldm/bin/decode -f /home/ldm/unisys/lic - /home/ldm/unisys/faa604/(\1:yy)(\1:mm)\1\2\3.faa

Data Content

This is a list of the channel contents including WMO and AWIPS header and data format:

Radar Data

WMO Header	AWIPS Header	Description	Format
SDUS91	BR2MNA	2km base reflectivity national mosaic (prod=140)	NIDS+
SDUS91	BR4MNA	4km base reflectivity national mosaic (prod=141)	NIDS+
SDUS91	BR8MNA	8km base reflectivity national mosaic (prod=142)	NIDS+
SDUS91	CR4MNA	4km composite reflectivity national mosaic (prod=27)	NIDS+
SDUS91	CR8MNA	8km composite reflectivity national mosaic (prod=28)	NIDS+
SDUS91	CP4MNA	4km composite reflectivity national mosaic, precip only (prod=103)	NIDS+
SDUS91	ET4MNA	4km echo top national mosaic (prod=95)	NIDS+
SDUS91	R14MNA	4km 1 hour precipitation national mosaic (prod=90)	NIDS+
SDUS91	RA4MNA	4km precipitation accumulation since 12Z mosaic (prod=101)	NIDS+
SDUS91	RD4MNA	4km 24 hour (daily) precipitation mosaic 12Z-12Z (prod=102)	NIDS+
SDUS91	SATMNA	Storm attribute table for all sites (prod=100)	NIDS+
SDxx91¹	BR2MRC	2km base reflectivity regional mosaic (prod=140)	NIDS+
SDxx91¹	RD2MRC	2km 24 hours (daily) regional precipitation 12Z-12Z (prod=106)	NIDS+

NOTES:
1 - Regional mosaics. The WMO header characters "xx" denote the region. These are: "NE" for northeast, "SE" for southeast, "NC" for north central, "SC" for south central, "CE" for central, "NW" for northwest and "SW" for southwest.

FORMAT: The NIDS+ format is essentially the NIDS rastor format. The source ID rather than being the site ID is a number greater than 10000 (10000 for national mosaics, 10001-10007 for the regional mosaics). The rastor data is placed on a Lambert Conformal projection centered at 98 west and having true latitudes of 33 and 45 north. The grid resolution is specified in the description for the product and the center of the projection is the latitude and longitude in the NIDS header.

Family Of Services/FAA Data

This is not stream data but 3 minute collectives. The contents of the files are identical to the stream data.

WMO Header	AWIPS Header	Description	Format
DPPS91	1xxPPS¹	Public products data (3 minute file)	ASCII
DDDS91	2xxDDS¹	Domestic data (3 minute files)	ASCII
DIDS91	3xxIDS¹	International data (3 minute files)	ASCII
DFAA91	4xxFAA¹	FAA 604 data (3 minute files)	ASCII

NOTES:
1 - The number "xx" denotes the minute of the hour for the particular data ranging from 00-57 every 3 minutes.

Difax Charts

The charts are the standard set of Difax charts distinguished by chart number and saved in PNG image format.

WMO Header	AWIPS Header	Description	Format
QDFX11	xxxDFX¹	Difax charts	PNG image

NOTES:
1 - The 3 digits "xxx" denote the difax chart number ranging from 001 to 290.

Satellite Imagery

These files are in two formats. The first is a rastor dump format. There is an ASCII header imbedded into the first several pixels of the image that describe the image size, time and type. Here is a sample:

hs107 x1024 y1024 wr11185 hr11185 iddisk_vis b2 ssn8 sln2 esn9164 eln2291 sr1 lr5 fld1007494368 v10137 end

The image size is defined in the "x" and "y" values. Other parameters can be used with navigation information specific to the satellite to do more precise navigation of the image.

The second format is standard GIF image format.

WMO Header	AWIPS Header	Description	Format
TIGM91	VFDGMS	Visible full disk GMS image	Rastor
TIGM91	IFDGMS	IR full disk GMS image	Rastor
TIGM91	WFDGMS	Water Vapor full disk GMS image	Rastor
TIGM91	VASGMS	Visible GMS image, eastern Asia sector	Rastor
TIGM91	IASGMS	IR GMS image, eastern Asia sector	Rastor
TIGM91	VINGMS	Visible GMS image, India sector	Rastor
TIGM91	IJKGMS	IR GMS image, Japan/Korea sector	Rastor
TIGM92	VFDGMS	Visible full disk GMS image	GIF image
TIGM92	IFDGMS	IR full disk GMS image	GIF image
TIGM92	WFDGMS	Water Vapor full disk GMS image	GIF image
TIGM92	VASGMS	Visible GMS image, eastern Asia sector	GIF image
TIGM92	IASGMS	IR GMS image, eastern Asia sector	GIF image
TIGM92	VNPGMS	Visible GMS image, north Pacific sector	GIF image
TIGM92	INPGMS	IR GMS image, north Pacific sector	GIF image
TIGM92	VINGMS	Visible GMS image, India sector	GIF image
TIGM92	IJKGMS	IR GMS image, Japan/Korea sector	GIF image
TIME91	VFDMET	Visible full disk Meteosat image	Rastor
TIME91	IFDMET	IR full disk Meteosat image	Rastor
TIME91	WFDMET	Water vapor full disk Meteosat image	Rastor
TIME91	VEUMET	Visible Meteosat image, Europe sector	Rastor
TIME91	IEUMET	IR Meteosat image, Europe sector	Rastor
TIME91	VPGMET	Visible Meteosat image, Persian Gulf sector	Rastor
TIME91	IPGMET	IR Meteosat image, Persian Gulf sector	Rastor

Encryption Key Files

WMO Header	AWIPS Header	Description	Format
NLIC99		Encryption key file	ASCII

Modified December 4, 2001 by Dan Vietor