The following describes the file structure of the event data file generated by the Siemens Power TG historian software, which is processed by the interface.
The first field of the file is a “magic number”, which is 2 bytes long and MUST contain 0x01 0x02. This is used to verify that the file being read is an event data file. If the file does not start with 0x01 0x02 then the interface will reject the file and output a file status of “Invalid”.
Following the “magic number”, the file contains the actual event data records. Each record is 58 bytes long. The fields within the event record are as followings.
Point ID (integer)
Field Name (string)
UTC Timestamp (SQL_TIMESTAMP structure)
Milliseconds timestamp (integer)
Value (IEEE single precision float)
Point Attribute / Quality flags (2 x 4 byte integers)
The following describes the file structure of the alarm message file generated by the Siemens Power TG historian software, which is processed by the interface.
The first field of the file is a “magic number”, which is 2 bytes long and MUST contain 0x03 0x04. This is used to verify that the file being read is an event data file. If the file does not start with 0x03 0x04 then the interface will reject the file and output a file status of “Invalid”.
Following the “magic number”, the file contains the actual alarm message records. The length of each record is variable. The fields within the event record are as followings.
UTC Timestamp (SQL_TIMESTAMP structure)
Sequence number (integer)
AOR Group (string)
Entity field length in bytes (integer)
Entity name (string
Message field length in bytes (integer)
Binary values are in are little endian format.
The sequence number, priority, AOR group, entity and alarm message are concatenated into a single string with “|” characters separating the fields for storing in the PI string points.
The data for the Power TG system is defined using the Source Database Builder (SDB). This database allows the user to configure the Power TG database off line and then install a set of changes in a block to the running system. The archiving of data to the PI system from the Power TG system is also defined using the SDB.
To set up archiving in the SDB, you open the “Data Warehouse” form using the “Data Warehouse” option on the “SCADA” menu or the “Archives” toolbar button. This form is used to define all archiving from the Power TG system including PI as well as to SQL Server and Oracle databases. The form has multiple tabs. The first tab marked “Data Warehouse” defines the attributes of the archive servers. The second tab marked “System Archive Groups” defines the collection of data from the Power TG system and sending that data to an archive server.
To set up a PI archive server, you first define the computer that will contain the PI database using the “Computer Definitions” form from the “Hardware” menu. If a PI collective will be used, you define the computer as the primary member of the collective. Next, you open the “Data Warehouse” form, select the “Data Warehouse” tab and click the “New Data Warehouse” button at the top right of the form. This will present a dialog box where you give the archive server its “entity name”, its “real time database name”, choose the database type of “PI” and select the computer name. After clicking on the checkmark button of the dialog box, the new archive server (data warehouse) object is defined in the SDB database.
On the “Data Warehouse” tab, the data entry fields for a PI server are interpreted as follows:
This is the name that will be presented to the Power TG operator in alarm messages and status display for this server.
This is the “Real Time Database Name” for this server. The sort order of the RTDB names of the archives on a system determines the order they occur in the TG system. This order determines the number used in the name of the buffer files to identify the server to which the data is to be sent. It is also used to define the location of the files used by the Automatic Point Synchronization (APS) application to transfer the PI tag definitions from the SDB to the PI database. This file is created on the SDB server in the directory “\lg\database\dat\PI\” where the “” portion of the path is substituted for this name.
This is the area of responsibility group in which alarms relating to the archive server will be presented. It also defines which operators have the ability to control the state of the archiving operation.
This the priority at which alarms relating to the status of the archiving will be presented.
This is the name of the computer or collective used for the PI database.
This is the “Point Source” name used in the PI database. If not specified, “TG” is used.
Choose “PI” for a PI database.
If PI buffering using “bufserv” is enabled and the status of the PI buffers is to be periodically checked to indicate the state of the archiving process, define this field with a string such as:
That is, the keyword “bufserv” followed by a colon (:) and then a comma separated list (with no imbedded spaces) of the names of the one or more PI servers to which the data is being sent.
When defined in this way, the TG process will run the BufStat utility every 30 seconds for each server listed and post alarms or event messages to the Power TG alarm summary when the connection state of a buffer changes. If all buffers are disconnected, the archiving will receive a status of FAILED.
PI Interface ID
This is the interface ID number used to identify the instance of the interface from the TG system to the PI server. If not specified, it defaults to a value of 1.
In the lower portion of the form is a list to specify AOR Groups and their retention period in the archive database. For the PI archive, the retention is defined on the PI server. This definition for a PI database indicates only if the messages in the AOR groups are sent to the archive. By default, messages are sent to the archive. If it is desired that a particular AOR group’s messages are not to be archived, it may be entered in this part of the form with a retention period of zero.