Pi interface for Siemens Spectrum Power tg (Linux)
Diagram of Hardware Connection
Download 0.55 Mb.
|
- Navigate this page:
- Principles of Operation
- Processing of the Event Data File
- Requesting Initial Values after a Point is added to the Interface
- Processing of the Alarm Message File
- Connection to PI Server Lost
- Failover
Diagram of Hardware ConnectionThe following illustrates a simple configuration for sending data from a single Power TG station to a stand-alone PI server. 
The PI SIPowerTG Interface establishes the initial connection to PI and reconnects to PI in the event that the connection is lost for some reason. If the Interface is started while the PI Server is down, the Interface will periodically try to establish a connection until the PI Server is up. When the Interface starts, the interface searches the PI Point Database for points that belong to the Interface and a point list is created for the interface. Once startup is complete, the Interface enters the processing loop, which includes: Every 0.5 seconds, the interface will check to see whether a measurement data file or an alarm message file has been created by the Power TG system. If a file is found, the interface will process the file. For details on the file processing, see the Processing of the Event Data File and the Processing of the Alarm Message File sections below. After processing, if the -renamedata= or -renamealarm= parameter has been specified then the interface will rename the file, so it can be processed by other applications. By default, the interface will delete the processed file and will wait for the next data file. The PI Point Database is checked every 2 minutes for points that are added, edited, and deleted. If point updates are detected, the points are loaded (or reloaded) by the Interface as appropriate. The 2-minute update interval can be adjusted with the
For each event, it will first decode the event and extract the value and quality. It will then search for any PI points that are configured for the id@field in the event. When it finds a point, it will format the data in the required format for the PI point and send the data to the PI system. Depending on the configuration of the PI point, the point can store the value from the Power TG field or the data quality, and the data quality can be represented in several formats. A keyword appended to the InstrumentTag is used to differentiate what the interface will store in the PI point. The interface is able to store value or a quality when the quality is bad value (regardless of the quality) data quality (priority based on data_qualities.ini definition) OPC QQSSSS quality OPC limit (LL) quality OPC special quality Alarm status (extracted from the quality flags) When storing the "value or quality", the interface will check the data quality. If the quality shows the value is meaningless then instead of writing the value to PI, it will write a suitable system digital status. (i.e. “Comm Fail” or “Out of Serv”) If the quality shows that the value is valid, but not scanned normally (a manual override value etc.) then the interface will sent the value to PI, but it will also set the PI questionable flag to highlight the fact that the value is not normal. Because the PI system is not able to store the entire data quality in the same point as the value, the interface is able to store the quality in a separate PI point. The interface will translate the quality of an event into either a data quality priority (same as the quality displayed on the operator displays), an OPC formatted quality values or an alarm status. This value can then be stored in a PI point. If the PI point is a digital then the interface will store a quality as an offset into the quality digital set. The definitions of the digital state sets expected by the interface are listed in the Quality Digital State Set section of the manual. When the interface processes data quality points (InstrumentTag ends with .QUAL), it uses data quality fields from the event record to calculate the quality priority. The interface reads the priorities from the Power TG configuration file defined with the -qualcodefile= argument. The Power TG system uses the same file to define the quality codes shown on the operator displays. Because it may not be appropriate the store some of the qualities in the PI system, the data_qualities.ini file contains a section called [PI] and qualities listed in this section with a FALSE value will skipped by the interface. If there are qualities listed in the data_qualities.ini that are not required to be stored in the PI data quality points, these can also be excluded by setting the quality flag in the [PI] section to FALSE. By default, the Selected_Field quality is excluded, but all other qualities are included. Once all the events in the buffer file have been processed, by default the interface will delete the data file. But, if the command-line parameter -rename= is set then the interface will attempt to rename the processed file. This is a way that the data file can be passed to another application for further processing (sending the same events to multiple historian systems). If the destination file already exists then the interface will NOT overwrite it. Instead, the interface will wait for the other application to process the old file and only after the destination file has been removed will the interface rename its data file. Finally, the interface will update any interface specific performance PI points. These performance points include a counter of the number of files processed, the timestamp of the latest event, the number events found in the file, the number of events sent to PI and the time taken to process the file. See the Interface Specific Performance Points section for more details. Requesting Initial Values after a Point is added to the InterfaceThe Power TG system can be configured to output new PI tag information or changed PI tag information to a comma separated file (csv file). This csv file is used by the Generic CSV plug-in to the Auto Point Synchronization (APS) utility to create and/or modify PI tags that belong to the interface. After the Power TG system outputs data to the csv, it can be more than 5 minutes before the interface receives this change to the PI point database. For this reason, the interface will not save the initial value from the Power TG system to the PI tag. This can lead to a situation where a PI tag’s value will remain in “Pt Created” until the value of that point on the Power TG system changes. In order to avoid this situation, the interface will request the current value by writing the Power TG point to an ASCII text file. The Power TG system will monitor a folder for a new text file. When the Power TG system sees a new text file, it will read the file and send the current value for any point found in the file. The /data command line parameter specifies the location and the name of the buffer data file. The location of the new tag file will be the same as the buffer data file. The name of the new tag file will be the same as the buffer data file except the extension will be changed to “.tags”. Any time the interface receives a new PI tag or a PI tag edit that does not cause the PI tag to be removed from the interface, the interface will write the Power TG point to a temporary new tag file. The temporary new tag file will have the same path and name as the buffer data file except the extension will be “.temp”. After the interface completes processing the current batch of point database edits, the interface will attempt to rename the file to have the “.tags” extension. If the location currently has a file with the “.tags” extension, the interface will wait 30 seconds and then check again to see if the new tags file has been processed by the Power TG system and then deleted. If any new tags come in prior to the Power TG system deleting the new tag file, the interface will append any new Power TG points to the end of the current temporary file.
Sequence (used to define the order of alarms when a group has the same timestamp) Priority AOR_Group Entity Message
For example, 0|3|GEN|ANALOG:AGCGHOST.GENACT_06|PUI_UN_01 GENERATOR ACTUAL MW RETURN TO NORM 34.000 32.759 0|999|GEN||AGC SYSTEM SUMMARY LGS FREQUENCY DEVIATION OFFSET IS -.050 WAS 0.000 The timestamp for the alarm is used by PI when storing the value, so the timestamp itself it not included within the string value. To locate the PI point that the interface will write an alarm to, it loops though the list of all alarm tags configured in the interface, and applies a filter for each point against the current alarm, and if a match is found then the alarm it written to that PI point. It is possible that one alarm will be sent to multiple PI points, depending on the filters configured for the alarm points. For example, all the high priority alarms could go to one PI point, or all the alarms from one plant area could go to another PI point. You can also have a PI point with no filter, which would capture all the alarm messages, but when analyzing the alarms there would be a lot of alarms that are irrelevant and would need to be removed. Filtering the alarms in different PI points when they are stored in PI can simplify the analysis of the collected alarm data. The alarm filters are defined in the InstrumentTag attribute of the PI point. The filter allows the alarms to be split into groups with each group being sent to a different PI point. The alarms can be filters on the Priority, AOR_Group and Entity fields. For example, if a PI point was to store all the alarms for the AOR Group labeled “GEN”, then the InstrumentTag would contain AOR_GROUP=GEN If a point was to store only the alarms with priority < 10 for the AOR group “GEN”, it use the InstrumentTag PRIORITY<10 AND AOR_GROUP=GEN Full details of the filtering are described in the PI Point Configuration section.
To enable to the Power TG system to know that the events are no longer reaching the PI server, the interface includes the -connected parameter. When this parameter is set, the interface will check the status of the connection to the PI server and if the interface is not able to communicate with the PI server, it will NOT process the current input files. The input files will only be processed when the connection to the PI server is good. The Power TG system is able to see that the input files are not being processed, so the events that it is collected are buffered in its own data files, so no data is lost. It is also able to generate an event to notify the Power TG users of the problem with the connection to the PI server. FailoverThe interface itself does not failover. The failover mechanism is performed by the Power TG system. However, the interface does need to be aware of the failover mechanism to minimize the amount of duplicate data send to the PI system. When there is a pair of redundant Power TG servers that can send data to PI, only one of these will be publishing the buffer files for the interface to process. When failover occurs, one will stop generating files (or shutdown entirely) and the other will start publishing the buffer files. Because the interface will only send data to PI when a buffer file is available it means that as soon as the server publishes the file, the interface will be able to process it. The problem with the above mechanism is that when the secondary server takes over, it publishes a buffer file with up to 30 minutes of data, some of which would have already been published by the primary interface. This overlap in the data files means that the PI system will receive a block of out-of-order data and duplicate events. Although the PI system can handle this overlapping data, it is better if it can be avoided. Therefore, the interface will do the following. When an interface has not been processing files for some time (either on startup or it has been on standby) and it then becomes active, the interface will attempt to read the snapshot value of the “latest timestamp” performance point, which was updated by the other instance of the interface. Once it has the “latest timestamp” value, the interface will process the data file normally, except that it will discard the all events that are older than the time retrieved. See the Interface Specific Performance Points sections for more details on the configuration of the “latest timestamp” performance point. If the “latest timestamp” performance point does not exist (not loaded by the interface) or the interface is unable to read the current value of the point because the connection to the PI server is down, the interface will send all of the events in the data file (discarding none). Because the interface is down, the events will be buffered by the PI API until the connection to restored, but it will allow the interface to continue processing the files normally. There may be some overlap and out-of-order events in the PI system, but no data will be lost. When the interface is running normally, it will not attempt to read the “latest timestamp” performance point. The discarding of events from the buffer file is only done when the interface is starting to process files, either on startup or when coming out of standby.
|