PI Interface for Siemens Spectrum Power TG (Windows)



PI Interface for Siemens Spectrum Power TG (Windows) Version 1.0.2OSIsoft, LLC 777 Davis St., Suite 250San Leandro, CA 94577 USATel: (01) 510-297-5800Fax: (01) 510-357-8136Web: Australia ? Perth, AustraliaOSIsoft Europe GmbH ? Frankfurt, GermanyOSIsoft Asia Pte Ltd. ? Singapore OSIsoft Canada ULC ? Montreal & Calgary, CanadaOSIsoft, LLC Representative Office ? Shanghai, People’s Republic of ChinaOSIsoft Japan KK ? Tokyo, JapanOSIsoft Mexico S. De R.L. De C.V. ? Mexico City, MexicoOSIsoft do Brasil Sistemas Ltda. ? Sao Paulo, BrazilPI Interface for Siemens Spectrum Power TG (Windows)Copyright: ? 2009- SAVEDATE \@ "YYYY" \* MERGEFORMAT 2013 OSIsoft, LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset Framework (PI AF), IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Coresight, PI Data Services, PI Event Frames, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.U.S. GOVERNMENT RIGHTSUse, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.Published: SAVEDATE \@ "MM/YYYY" \* MERGEFORMAT 04/2013Table of Contents TOC \o "1-3" \h Chapter 1.Introduction PAGEREF _Toc354483551 \h 1Reference Manuals PAGEREF _Toc354483552 \h 1Supported Operating Systems PAGEREF _Toc354483553 \h 2Supported Features PAGEREF _Toc354483554 \h 2Diagram of Hardware Connection PAGEREF _Toc354483555 \h 5Chapter 2.Principles of Operation PAGEREF _Toc354483556 \h 7Chapter 3.Installation Checklist PAGEREF _Toc354483557 \h 13Data Collection Steps PAGEREF _Toc354483558 \h 13Interface Diagnostics PAGEREF _Toc354483559 \h 14Advanced Interface Features PAGEREF _Toc354483560 \h 15Chapter 4.Interface Installation on Windows PAGEREF _Toc354483561 \h 17Naming Conventions and Requirements PAGEREF _Toc354483562 \h 17Interface Directories PAGEREF _Toc354483563 \h 18PIHOME Directory Tree PAGEREF _Toc354483564 \h 18Interface Installation Directory PAGEREF _Toc354483565 \h 18Interface Installation Procedure PAGEREF _Toc354483566 \h 18Installing Interface as a Windows Service PAGEREF _Toc354483567 \h 18Installing Interface Service with PI?Interface?Configuration?Utility PAGEREF _Toc354483568 \h 19Service Configuration PAGEREF _Toc354483569 \h 19Installing Interface Service Manually PAGEREF _Toc354483570 \h 22Chapter 5.DumpInputFile Utility PAGEREF _Toc354483571 \h 23Chapter 6.DumpAlarmFile Utility PAGEREF _Toc354483572 \h 25Chapter 7.BufStat Utility PAGEREF _Toc354483573 \h 27Chapter 8.Digital States PAGEREF _Toc354483574 \h 29Chapter 9.PointSource PAGEREF _Toc354483575 \h 33Chapter 10.PI Point Configuration PAGEREF _Toc354483576 \h 35Point Attributes PAGEREF _Toc354483577 \h 35Tag PAGEREF _Toc354483578 \h 35PointSource PAGEREF _Toc354483579 \h 36PointType PAGEREF _Toc354483580 \h 36Location1 PAGEREF _Toc354483581 \h 36Location2 PAGEREF _Toc354483582 \h 36Location3 PAGEREF _Toc354483583 \h 36Location4 PAGEREF _Toc354483584 \h 37Location5 PAGEREF _Toc354483585 \h 37InstrumentTag PAGEREF _Toc354483586 \h 37ExDesc PAGEREF _Toc354483587 \h 39Scan PAGEREF _Toc354483588 \h 39Shutdown PAGEREF _Toc354483589 \h 40Chapter 11.Startup Command File PAGEREF _Toc354483590 \h 41Configuring the Interface with PI ICU PAGEREF _Toc354483591 \h 41SIPowerTG Interface Page PAGEREF _Toc354483592 \h 44Command-line Parameters PAGEREF _Toc354483593 \h 47Sample PISIPowerTG.bat File PAGEREF _Toc354483594 \h 52Chapter 12.Interface Specific Failover PAGEREF _Toc354483595 \h 53Introduction PAGEREF _Toc354483596 \h 53Point Configuration for Failover PAGEREF _Toc354483597 \h 54Chapter 13.Interface Node Clock PAGEREF _Toc354483598 \h 57Windows PAGEREF _Toc354483599 \h 57Chapter 14.Security PAGEREF _Toc354483600 \h 59Windows and UNIX PAGEREF _Toc354483601 \h 59Chapter 15.Starting / Stopping the Interface on Windows PAGEREF _Toc354483602 \h 61Starting Interface as a Service PAGEREF _Toc354483603 \h 61Stopping Interface Running as a Service PAGEREF _Toc354483604 \h 61Chapter 16.Buffering PAGEREF _Toc354483605 \h 63Which Buffering Application to Use PAGEREF _Toc354483606 \h 63How Buffering Works PAGEREF _Toc354483607 \h 64Buffering and PI Server Security PAGEREF _Toc354483608 \h 64Enabling Buffering on an Interface Node with the ICU PAGEREF _Toc354483609 \h 65Choose Buffer Type PAGEREF _Toc354483610 \h 65Buffering Settings PAGEREF _Toc354483611 \h 66Buffered Servers PAGEREF _Toc354483612 \h 68Installing Buffering as a Service PAGEREF _Toc354483613 \h 71Chapter 17.Interface Diagnostics Configuration PAGEREF _Toc354483614 \h 75Interface Specific Performance Points PAGEREF _Toc354483615 \h 75Sample Interface Specific Performance Points PAGEREF _Toc354483616 \h 76Scan Class Performance Points PAGEREF _Toc354483617 \h 76Performance Counters Points PAGEREF _Toc354483618 \h 76Performance Counters PAGEREF _Toc354483619 \h 78Performance Counters for both (_Total) and (Scan Class x) PAGEREF _Toc354483620 \h 78Performance Counters for (_Total) only PAGEREF _Toc354483621 \h 80Performance Counters for (Scan Class x) only PAGEREF _Toc354483622 \h 82Interface Health Monitoring Points PAGEREF _Toc354483623 \h 84Failover configurations with UniInt Health Points PAGEREF _Toc354483624 \h 89Sample UniInt Health Points PAGEREF _Toc354483625 \h 90I/O Rate Point PAGEREF _Toc354483626 \h 90Interface Status Point PAGEREF _Toc354483627 \h 92Appendix A.Error and Informational Messages PAGEREF _Toc354483628 \h 95Message Logs PAGEREF _Toc354483629 \h 95Messages PAGEREF _Toc354483630 \h 95Startup PAGEREF _Toc354483631 \h 95Loading PI points PAGEREF _Toc354483632 \h 96Data File Processing PAGEREF _Toc354483633 \h 99Alarm File Processing PAGEREF _Toc354483634 \h 100Getting Latest Timestamp PAGEREF _Toc354483635 \h 100System Errors and PI Errors PAGEREF _Toc354483636 \h 101Appendix B.PI SDK Options PAGEREF _Toc354483637 \h 103Appendix C.Event Data File Structure PAGEREF _Toc354483638 \h 105Appendix D.Alarm Message File Structure PAGEREF _Toc354483639 \h 107Appendix E.Setting up a PI Archive on the Power TG System PAGEREF _Toc354483640 \h 109PI Server Definition PAGEREF _Toc354483641 \h 109Point Collection Definition PAGEREF _Toc354483642 \h 112Installing Data from the SDB for a PI Archive PAGEREF _Toc354483643 \h 114Terminology PAGEREF _Toc354483644 \h 115Appendix F.Technical Support and Resources PAGEREF _Toc354483645 \h 119Before You Call or Write for Help PAGEREF _Toc354483646 \h 119Help Desk and Telephone Support PAGEREF _Toc354483647 \h 119Search Support PAGEREF _Toc354483648 \h 120Email-based Technical Support PAGEREF _Toc354483649 \h 120Online Technical Support PAGEREF _Toc354483650 \h 120Remote Access PAGEREF _Toc354483651 \h 121On-site Service PAGEREF _Toc354483652 \h 121Knowledge Center PAGEREF _Toc354483653 \h 121Upgrades PAGEREF _Toc354483654 \h 121OSIsoft Virtual Campus (vCampus) PAGEREF _Toc354483655 \h 121Appendix G.Revision History PAGEREF _Toc354483656 \h 123IntroductionThe PI Interface for Siemens Spectrum Power TG (SIPowerTG) allows real-time data from the Siemens Spectrum Power TG system to be written to a PI system. The interface runs on the Siemens Power TG host station and processes data files generated by the Power TG HIS software.The interface is available for both Windows and Linux (64-bit) platforms, and both versions have the same functionality. There are differences in the installation and configuration of the interfaces. This manual covers the Linux version of the interface.The interface does not allow data from the PI system to be written to the Siemens Power TG system. The interface does not support UniInt failover. However, by using the Power TG functionality, interface redundancy is supported.Note: The value of [PIHOME] variable for the 32-bit interface will depend on whether the interface is being installed on a 32-bit operating system (C:\Program?Files\PIPC) or a 64bit operating system (C:\Program?Files?(x86)\PIPC). The value of [PIHOME64] variable for a 64-bit interface will be C:\Program?Files\PIPC on the 64-bit operating system.In this documentation [PIHOME] will be used to represent the value for either [PIHOME] or [PIHOME64]. The value of [PIHOME] is the directory which is the common location for PI client applications.Note: Throughout this manual there are references to where messages are written by the interface which is the PIPC.log. This interface has been built against a UniInt version (4.5.0.59 and later) which now writes all its messages to the local PI Message log.Please note that any place in this manual where it references PIPC.log should now refer to the local PI message log. Please see the document UniInt Interface Message Logging.docx in the %PIHOME%\Interfaces\UniInt directory for more details on how to access these messages.Reference ManualsOSIsoftPI Server manualsPI API Installation Instructions manualUniInt Interface User ManualSupported Operating SystemsPlatforms32-bit application64-bit applicationWindows XP32-bit OSYesNo64-bit OSYes (Emulation Mode)NoWindows 2003 Server32-bit OSYesNo64-bit OSYes (Emulation Mode)NoWindows Vista32-bit OSYesNo64-bit OSYes (Emulation Mode)NoWindows 200832-bit OSYesNoWindows 2008 R264-bit OSYes (Emulation Mode)NoWindows 732-bit OSYesNo64-bit OSYes (Emulation Mode)NoWindows 832-bit OSYesNo64-bit OSYes (Emulation Mode)NoWindows 201264-bit OSYes (Emulation Mode)NoThe interface is designed to run on the Microsoft Windows operating systems. Because it is dependent on vendor software, newer platforms may not yet be supported.Please contact OSIsoft Technical Support for more information.Supported FeaturesFeatureSupportInterface Part NumberPI-IN-SI-PTG-NTIAuto Creates PI PointsYes (using Generic_CSV APS Connector)Point Builder UtilityNoICU ControlYesPI Point Typesfloat64 / float32 / float16 / int32 / int16 / digital / stringSub-second TimestampsYesSub-second Scan ClassesNoAutomatically Incorporates PI?Point Attribute ChangesYesException ReportingYesOutputs from PINoInputs to PI:UnsolicitedSupports Questionable BitYesSupports Multi-character PointSourceYesMaximum Point CountUnlimited* Uses PI SDKNoPINet String SupportNo* Source of TimestampsPower TGHistory RecoveryNo* UniInt-based* Disconnected Startup* SetDeviceStatusYesYesYes* FailoverInterface specific failover* Vendor Software Required on Interface Node / PINet NodeYesVendor Software Required on Foreign DeviceYesVendor Hardware RequiredNoAdditional PI Software Included with interfaceYesDevice Point TypesAll types supported by the Power TG historian software including alarm and event messagesSerial-Based interfaceNo* See paragraphs below for further explanation.Uses PI SDKThe PI SDK and the PI API are bundled together and must be installed on each interface node. This interface does not specifically make PI SDK calls.Source of TimestampsThe data received from the Power TG system includes a UTC timestamp for each event. That timestamp is passed to the PI server with the event values.UniInt-basedUniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoftdeveloped template used by developers and is integrated into many interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of OSIsoft’s interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniIntsupplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.The UniInt Interface User Manual is a supplement to this manual.Disconnected Start-UpThe SIPowerTG interface is built with a version of UniInt that supports disconnected start-up. Disconnected start-up is the ability to start the interface without a connection to the PI Server. This functionality is enabled by adding /cachemode to the list of start-up parameters or by enabling disconnected startup using the ICU. Refer to the UniInt Interface User Manual for more details on UniInt disconnected startup.SetDeviceStatusFunctionality has been added to UniInt 4.3.0.15 and later to support health tags. The PISIPowerTG interface is built against a version of UniInt that supports the health tags. The Health tag with a string point type and the attribute ExDesc = [UI_DEVSTAT], is used to represent the status of the interface. The possible values for this string point are:“1 | Starting” – The Interface remains in this state until it has successfully collected data from its first scan.“Good” – The interface is able to collect data. A value of “Good” does not mean that all tags are receiving good values, but it is a good indication that there are no hardware or network problems.“4 | Intf Shutdown” – The Interface has shut down.The Interface updates this point whenever the interface is started or stopped.FailoverThe interface itself does not support failover. However, the Power TG system does support failover between stations. This means that if an instance of the interface is run on both stations, when the station fails over, the interface on the active station will send events to the PI server. See section Interface Specific Failover for more details.Vendor Software RequiredPower TG Historian (HIS) software version 8.3 SP1or greater is required to generate the event data and message data files used by the interface. The interface runs directly on the Power TG historian machine.Additional PI SoftwareTwo utilities are included with the interface to allow the input files from the Power TG system to be dumped to stdout and can be used to validate the raw data that the interface will be reading. The utilities are DumpInputFile and DumpAlarmFile. The utility BufStat is also included to allow the Power TG system to evaluation the status of the connections to the PI Server when bufserv is used.Device Point TypesThe interface can support any measurement point type and field that is encoded in the event data files or any alarm or event message stored in the alarm files produced by the Power TG historian software.Diagram of Hardware ConnectionThe following illustrates a simple configuration for sending data from a single Power TG station to a stand-alone PI server.Principles of OperationThe 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 /updateinterval command-line parameter discussed in the UniInt Interface User Manual. The Interface will only process 25 point updates at a time. If more than 25 points are added, edited, or deleted at one time, the Interface will process the first 25 points, wait 30 seconds (or by the time specified by the /updateinterval parameter, whichever is lower), process the next 25 points, and so on. Once all points have been processed, the Interface will resume checking for updates every 2 minutes (or by the time specified by the /updateinterval parameter). The Interface will write the digital state SCAN OFF to any points that are removed from the Interface while it is running.Processing of the Event Data FileThe interface reads each of the events from the buffer event data file.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 badvalue (regardless of the quality)data quality (priority based on data_qualities.ini definition)OPC QQSSSS qualityOPC limit (LL) qualityOPC special qualityAlarm 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.Processing of the Alarm Message FileThe interface loops though all the alarm messages in the alarm file, processing each alarm message in turn. The message is formatted into a string for storing in the PI system. The string consists of the all the fields separated with a pipe ‘|’ character. The fields within the alarm are Sequence (used to define the order of alarms when a group has the same timestamp)PriorityAOR_GroupEntityMessageFor example,0|3|GEN|ANALOG:AGCGHOST.GENACT_06|PUI_UN_01 GENERATOR ACTUAL MW RETURN TO NORM 34.000 32.7590|999|GEN||AGC SYSTEM SUMMARY LGS FREQUENCY DEVIATION OFFSET IS -.050 WAS 0.000The 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 containAOR_GROUP=GENIf a point was to store only the alarms with priority < 10 for the AOR group “GEN”, it use the InstrumentTagPRIORITY<10 AND AOR_GROUP=GENFull details of the filtering are described in the PI Point Configuration section.Connection to PI Server LostBy default, when the connection to the PI server is lost, the interface will continue to process the input files normally, but the events sent to PI will be buffered by the PI API. When the connection is restored, then buffers are sent to PI. With this configuration, there is no indication to the Power TG system that there is a problem with the connection to PI.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.Installation ChecklistIf you are familiar with running PI data collection interface programs, this checklist helps you get the interface running. If you are not familiar with PI interfaces, return to this section after reading the rest of the manual in detail.This checklist summarizes the steps for installing this interface. You need not perform a given task if you have already done so as part of the installation of another interface. For example, you only have to configure one instance of Buffering for every interface node regardless of how many interfaces run on that node.The Data Collection Steps below are required. Interface Diagnostics and Advanced Interface Features are optional.Data Collection StepsConfirm that you can use PI SMT to configure the PI Server. You need not run PI SMT on the same computer on which you run this interface.If you are running the interface on an interface node, edit the PI Server’s Trust Table to allow the interface to write data.Run the installation kit for the PI Interface Configuration Utility (ICU) on the interface node if the ICU will be used to configure the interface. This kit runs the PI SDK installation kit, which installs both the PI API and the PI SDK. Run the installation kit for this interface. This kit also runs the PI SDK installation kit which installs both the PI API and the PI SDK if necessary.If you are running the interface on an interface node, check the computer’s time zone properties. An improper time zone configuration can cause the PI Server to reject the data that this interface writes.Run the ICU and configure a new instance of this interface. Essential startup parameters for this interface are:Point Source (/PS=x)Interface ID (/ID=#)PI Server (/Host=host:port) Measurement Data File (/DATA=x)Alarm Message File (/ALARM=x)Quality Code File (/QUALCODEFILE=x)Do NOT configure Scan Classes (/F=##:##:##,offset)Use the DumpInputFile and DumpAlarmFile utilities to confirm the format of a sample event data and alarm message files.If you will use digital points, define the appropriate digital state sets. The sample file SIPowerTG_digital_set.csv can be imported with PI SMT to create the file status and default quality digital sets.Check the contents of the data quality definition file (data_qualitities.ini) and ensure that the TG_DATA_QUALITY digital state set matches the priorities defined in the file.Build input tags and, if desired, output tags for this interface. Important point attributes and their purposes are:Location1 specifies the interface instance ID.Location2 specifies the point type (performance, value or alarm).Location3 is not used.Location4 MUST be zero. (All points are unsolicited)Location5 specifies whether debug messages will be logs for this point.ExDesc not used by the interface. Normally set to the Power TG point name.InstrumentTag specifies the Power TG point number, field and data type for measurement data points or the filter expression for alarm points.Start the interface interactively and confirm its successful connection to the PI Server without buffering.Confirm that the interface collects data successfully.Stop the interface and configure a buffering application (either Bufserv or PIBufss). When configuring buffering use the ICU menu item Tools Buffering… Buffering Settings to make a change to the default value (32678) for the Primary and Secondary Memory Buffer Size (Bytes) to 2000000. This will optimize the throughput for buffering and is recommended by OSIsoft.Start the buffering application and the interface. Confirm that the interface works together with the buffering application by either physically removing the connection between the interface node and the PI Server Node or by stopping the PI Server.Configure the interface to run as a Service. Confirm that the interface runs properly as a Service.Restart the interface node and confirm that the interface and the buffering application restart.Interface DiagnosticsConfigure the Interface Specific performance points.Install the PI Performance Monitor Interface (Full Version only) on the interface node.Configure Performance Counter points.Configure UniInt Health Monitoring pointsConfigure the I/O Rate point.Install and configure the Interface Status Utility on the PI Server Node.Configure the Interface Status point.Advanced Interface FeaturesConfigure the interface for disconnected startup. Refer to the UniInt Interface User Manual for more details on UniInt disconnected startup.Interface Installation on Windows OSIsoft recommends that interfaces be installed on interface nodes instead of directly on the PI?Server node. An interface node is any node other than the PI Server node where the PI?Application Programming Interface (PI API) is installed (see the PI API?manual). With this approach, the PI Server need not compete with interfaces for the machine’s resources. The primary function of the PI?Server is to archive data and to service clients that request data. After the interface has been installed and tested, Buffering should be enabled on the interface node. Buffering refers to either PI API Buffer Server (Bufserv) or the PI Buffer Subsystem (PIBufss). For more information about Buffering see the Buffering chapter of this manual.In most cases, interfaces on interface nodes should be installed as automatic services. Services keep running after the user logs off. Automatic services automatically restart when the computer is restarted, which is useful in the event of a power failure.The guidelines are different if an interface is installed on the PI Server node. In this case, the typical procedure is to install the PI Server as an automatic service and install the interface as an automatic service that depends on the PI Update Manager and PI Network Manager services. This typical scenario assumes that Buffering is not enabled on the PI Server node. Bufserv or PIBufss can be enabled on the PI Server node so that interfaces on the PI Server node do not need to be started and stopped in conjunction with the PI Server, but it is not standard practice to enable buffering on the PI Server node. The PI Buffer Subsystem can also be installed on the PI Server. See the UniInt Interface User Manual for special procedural information.Naming Conventions and RequirementsIn the installation procedure below, it is assumed that the name of the interface executable is PISIPowerTG.exe and that the startup command file is called PISIPowerTG.bat. When Configuring the Interface ManuallyIt is customary for the user to rename the executable and the startup command file when multiple copies of the interface are run. For example, PISIPowerTG1.exe and PISIPowerTG1.bat would typically be used for instance 1, PISIPowerTG2.exe and PISIPowerTG2.bat for instance 2, and so on. When an interface is run as a service, the executable and the command file must have the same root name because the service looks for its command-line parameters in a file that has the same root name.Interface DirectoriesPIHOME Directory Tree32-bit InterfacesThe [PIHOME] directory tree is defined by the PIHOME entry in the pipc.ini?configuration file. This pipc.ini file is an ASCII text file, which is located in the %windir% directory. For 32-bit operating systems, a typical pipc.ini file contains the following lines:[PIPC]PIHOME=C:\Program?Files\PIPCFor 64-bit operating systems, a typical pipc.ini file contains the following lines:[PIPC]PIHOME=C:\Program?Files (X86)\PIPCThe above lines define the root of the PIHOME directory on the C: drive. The PIHOME directory does not need to be on the C: drive. OSIsoft recommends using the paths shown above as the root PIHOME directory name. Interface Installation DirectoryThe interface install kit will automatically install the interface to:PIHOME\Interfaces\SIPowerTG\PIHOME is defined in the pipc.ini file.Interface Installation ProcedureThe SIPowerTG interface setup program uses the services of the Microsoft Windows Installer. Windows Installer is a standard part of Windows 2000 and later operating systems. To install, run the appropriate installation kit. SIPowerTG_#.#.#.#_.exe Installing Interface as a Windows ServiceThe SIPowerTG interface service can be created, preferably, with the PI?Interface?Configuration?Utility, or can be created manually.Installing Interface Service with PI?Interface?Configuration?UtilityThe PI?Interface?Configuration?Utility provides a user interface for creating, editing, and deleting the interface service:Service ConfigurationService nameThe Service name box shows the name of the current interface service. This service name is obtained from the interface executable.IDThis is the service ID used to distinguish multiple instances of the same interface using the same executable. Display nameThe Display name text box shows the current Display Name of the interface service. If there is currently no service for the selected interface, the default Display Name is the service name with a “PI-” prefix. Users may specify a different Display Name. OSIsoft suggests that the prefix “PI-” be appended to the beginning of the interface name to indicate that the service is part of the OSIsoft suite of products.Log on asThe Log on as text box shows the current “Log on as” Windows User Account of the interface service. If the service is configured to use the Local System account, the Log on as text box will show “LocalSystem.” Users may specify a different Windows User account for the service to use.PasswordIf a Windows User account is entered in the Log on as text box, then a password must be provided in the Password text box, unless the account requires no password.Confirm passwordIf a password is entered in the Password text box, then it must be confirmed in the Confirm password text box.DependenciesThe Installed services list is a list of the services currently installed on this machine. Services upon which this interface is dependent should be moved into the Dependencies list using the button. For example, if API Buffering is running, then “bufserv” should be selected from the list at the right and added to the list on the left. To remove a service from the list of dependencies, use the button, and the service name will be removed from the Dependencies list.When the interface is started (as a service), the services listed in the dependency list will be verified as running (or an attempt will be made to start them). If the dependent service(s) cannot be started for any reason, then the interface service will not run. Note: Please see the PI Log and Windows Event Logger for messages that may indicate the cause for any service not running as expected. - Add ButtonTo add a dependency from the list of Installed services, select the dependency name, and click the Add button. - Remove ButtonTo remove a selected dependency, select the service name in the Dependencies list, and click the Remove button. The full name of the service selected in the Installed services list is displayed below the Installed services list box.Startup TypeThe Startup Type indicates whether the interface service will start automatically or needs to be started manually on reboot.If the Auto option is selected, the service will be installed to start automatically when the machine reboots.If the Manual option is selected, the interface service will not start on reboot, but will require someone to manually start the service.If the Disabled option is selected, the service will not start at all.Generally, interface services are set to start automatically.CreateThe Create button adds the displayed service with the specified Dependencies and with the specified Startup Type. Remove The Remove button removes the displayed service. If the service is not currently installed, or if the service is currently running, this button will be grayed out. Start or Stop ServiceThe toolbar contains a Start button and a Stop button . If this interface service is not currently installed, these buttons will remain grayed out until the service is added. If this interface service is running, the Stop button is available. If this service is not running, the Start button is available.The status of the interface service is indicated in the lower portion of the PI ICU dialog.401383522860000256222522606000357568566040Service installed or uninstalled00Service installed or uninstalled120015070485Status of the ICU00Status of the ICU211074073660Status of the Interface Service00Status of the Interface ServiceNote: When starting the interface from the ICU, the following message may be displayed. Because the interface does not use scan classes, select Yes and the interface will be started. To stop the message being displayed every time the interface is started, select "Do not display this message again for this interface."Installing Interface Service ManuallyHelp for installing the interface as a service is available at any time with the command:PISIPowerTG.exe /help Open a Windows command prompt window and change to the directory where the PISIPowerTG1.exe executable is located. Then, consult the following table to determine the appropriate service installation command.Note: In the following Windows Service Installtation Commands you may use either a slash (/) or dash (-) as the delimiter.Windows Service Installation Commands on an Interface Node or a PI Server Node with Bufserv implementedManual servicePISIPowerTG.exe /install /depend "tcpip bufserv"Automatic servicePISIPowerTG.exe /install /auto /depend "tcpip bufserv"*Automatic service with service IDPISIPowerTG.exe /serviceid X /install /auto /depend "tcpip bufserv"Windows Service Installation Commands on an Interface Node or a PI Server Node without Bufserv implementedManual servicePISIPowerTG.exe /install /depend tcpipAutomatic servicePISIPowerTG.exe /install /auto /depend tcpip*Automatic service with service IDPISIPowerTG.exe /serviceid X /install /auto /depend tcpip*When specifying service ID, the user must include an ID number. It is suggested that this number correspond to the interface ID (/id) parameter found in the interface .bat file.Check the Microsoft Windows Services control panel to verify that the service was added successfully. The services control panel can be used at any time to change the interface from an automatic service to a manual service or vice versa. DumpInputFile UtilityThe DumpInputFile utility is installed as part of the interface kit and is located in the PIHOME\interface\SIPowerTG directory.It is a simple command-line program that can be used to print the contents of a Power TG data file. It will list each of the events within the file, including the point number, field, type, timestamp, value and quality flags.The command syntax isDumpInputFile [filename]where filename is the name of the Power TG data file to be output.For example:DumpInputFile D:\lg\scada\dat\his\measdata.his.1.PI.dat1 3528@STATE STATUS_DEFAULT 06-02-2009 14:45:35.000 (1233931535.000) 1 0x00070001 0x000000022 3528@TOT_OPS INT_FIELD 06-02-2009 14:45:35.000 (1233931535.000) 0 0x00000000 0x000000003 3529@STATE STATUS_DEFAULT 06-02-2009 14:45:35.000 (1233931535.000) 1 0x00010001 0x000000024 3529@TOT_OPS INT_FIELD 06-02-2009 14:45:35.000 (1233931535.000) 0 0x00000000 0x00000000<...snipped...>52 28374@VALUE ANALOG_DEFAULT 06-02-2009 14:45:35.000 (1233931535.000) 1.5809 0x00070000 0x00000002DumpAlarmFile UtilityThe DumpAlarmFile utility is installed as part of the interface kit and is located in the PIHOME/interface/SIPowerTG directory.It is a simple command-line program that can be used to print the contents of a Power TG alarm file. It will list each of the events within the file, including the timestamp, sequence, priority, AOR group, entity and alarm message.The command syntax isDumpAlarmFile [filename]where filename is the name of the Power TG alarm file to be output.For example:DumpAlarmFile D:\lg\scada\dat\his\msgdata.his.1.PI.dat1 18-03-2009 21:28:37.285 (1237411717.285) 0|28|GEN| ANALOG:AGCGHOST.GENACT_06|PUI_UN_01 GENERATOR ACTUAL MW RETURN TO NORM 34.000 32.7592 18-03-2009 21:28:37.285 (1237411717.285) 1|999|GEN| ANALOG:AGCGHOST.GENACT_06|PUI_UN_01 GENERATOR ACTUAL MW RETURN3 18-03-2009 21:28:37.285 (1237411717.285) 3|3|GEN| ANALOG:AGCGHOST.BASEPT_06|PUI_UN_01 BASE POINT RETURN TO NORM 34.000 32.759BufStat UtilityThe BufStat utility is installed as part of the interface kit and is located in the PIHOME\interface\SIPowerTG directory.This utility can be used to check the current connection status of a buffered PI server. It can also print the configuration of the bufserv parameters and the detailed status of the buffers. Typically, it will be used to allow the Siemens software to retrieve the PI server connection status so that it is able to notify operators when a PI server connection is lost.The command syntax isBufStat [options] PIserverwhere PIServer is the name of the PI server to be checked. Valid options are-cfgConfiguration of bufserv parameters-stat Buffer status-conConnection statusThe return status of the utility is0 Disconnected1Connected-1Fatal ErrorFor example,To print out the current status of the buffers, use the followingBufStat -stat XXXXXBufServ Status Info PI Server Status : Connected BufServ Status : Single Buffer 1 WriteLoc : 448 Buffer 1 Read Loc : 36 Buffer 1 Wrap Loc : 0 Buffer 1 Entries : 16 Buffer 1 Used : 412 ( 0.04%) Buffer 2 WriteLoc : 36 Buffer 2 Read Loc : 36 Buffer 2 Wrap Loc : 0 Buffer 2 Entries : 0 Buffer 2 Used : 0 ( 0.00%) File Entries : 0 File Size : 0 kBytesTo show the current connection status only, use the followingBufStat -con XXXXXXCONNECTEDTo use the BufStat is a script to get the current connection status, use the return code from the utility. The following .bat file runs the BufStat utility and then outputs the return code (%ERRORLEVEL% is the return code variable)@echo offBufStat XXXXXXecho XXXXXX =%ERRORLEVEL%Digital StatesFor more information regarding Digital States, refer to the PI Server documentation.Digital State SetsPI digital states are discrete values represented by strings. These strings are organized in PI as digital state sets. Each digital state set is a user-defined list of strings, enumerated from 0 to n to represent different values of discrete data. For more information about PI?digital tags and editing digital state sets, see the PI Server manuals.An interface point that contains discrete data can be stored in PI as a digital point. A digital?point associates discrete data with a digital state set, as specified by the user.Typically, these digital sets can be used for data likeOFF, ONOPEN, CLOSEDUNDEFINED, OPEN, CLOSE, TRANSITIONQuality Digital State SetThe following digital sets define the states for different types of points supported by the interface. These digital sets can be created by importing the SIPowerTG_DigitalSets.csv file with the SMT Digital Set plug-in, or by creating the digital sets manually.TG_DATA_QUALITY - Quality Priority Digital Set Location2 = 0, InstrumentTag ends with .QUALThe Data Quality points can be used to show the status of a Power TG point. It is based on the data qualities displayed on the operator displays and uses the data_qualities.ini file to calculate the quality state to send to the data quality PI points.Note 1 : Care must be taken to ensure that the definition of the TG_DATA_QUALITY digital set matches the definition given in the data_qualities.ini file (and data_qualities.project.ini if it exists). If there is a mismatch then misleading information will be shown on the PI displays.Note 2 : If the number of states in the digital set is not sufficient to store the priorities defined in the data_qualities.ini files then the points will be rejected by the interface.OffsetState TextDescription0(blank)No quality flags set1*Field Selected (disabled by default)2SState Estimator Update3MManually entered4DOut of Scan5#Floating Point Exception6TRTU Test Mode7FTelemetry Failure8UUninitialized9ZMissing10RReasonability Failure11?Questionable12XDrift13QComputed Value Based on Manually Entered Data14EState Estimator Error15BBackup Data16IAll Alarms Inhibited17WWarning Limit Alarms Inhibited18CDevice Comment19NIn Control20!Control Connection Failed21/Local/Remote22HAnalog High Operating23LAnalog Low Operating24HAnalog High Warning25LAnalog Low Warning26VLimit Override27OAbnormal28YExecution of switching control29AUnacknowledged AlarmTG_ALARM_STATUS - Alarm Status Digital Set Location2 = 0, InstrumentTag ends with .ALARMTo show the current alarm status of an analog point, the interface supports an alarm status point which will get the alarm status from the data quality of the event and write one of the following statesOffsetState TextDescription0NormalNo alarm conditions apply1Low WarningLow warning flag is set2Low AlarmLow alarm flag is set3High WarningHigh warning flag is set4High AlarmHigh alarm flag is setTG_QUAL_QQSSSS - OPC “QQSSSS” Digital Set Location2 = 0, InstrumentTag ends with .QQSSSSOffsetState TextOPC QualityQQ SSSSDescription0Good11 0000Good. No special conditions1ManOverride11 0100Good. Value has been manually overridden2Calc Man Val11 0111Good. Calculation based on manual override3Local11 1000Good. Local4Test Mode11 1001Good. Test mode5Backup11 1010Good. Backup6SE Update11 1011Good. SE Update7EU Exceeded01 0101Uncertain. Engineering units exceeded8Un-Initial01 0111Uncertain. Value un-initialized9Question01 1000Uncertain. Value questionable10Missing01 1001Uncertain. Missing11FP Exception01 1011Uncertain. Floating point exception12Comm Fail00 0110Bad. Communications failure13Out of Scan00 0111Bad. Out of scan14SE Bad00 1000Bad. SE badTG_QUAL_LIMIT - OPC Limit Status Digital Set Location2 = 0, InstrumentTag ends with .LIMITOffsetState TextDescription0NormalNo limit conditions apply1Low AlarmEither a low alarm or a low warning flag is set2High AlarmEither a high alarm or a high warning flag is setTG_QUAL_SPECIAL - OPC Special Quality Digital Set Location2 = 0, InstrumentTag ends with .SPECIALOffsetState TextDescription0NormalNo special conditions apply1In ControlIn Control2Alarm InhAlarms inhibited3Warning InhWarnings inhibited4Device CmntDevice comment present5Cmnd FailCommand failed6DriftDrift flag set7Limit OvrdLimit override8UnackUnacknowledged alarm9Excd AlarmExceeded alarm limit (can be either high or low limit)10Excd WarningExceeded warning limit (can be either high or low limit)File Status State SetOne of the interface-specific performance points shows the status of the last file processed. The File Status digital set is used to represent that status.TG_FILE_STATUS - File Status Digital SetLocation2 = -1, ExDesc = ”DATA_FILE_STATUS” or ExDesc = ”ALARM_FILE_STATUS”OffsetState TextDescription0InvalidFile magic number is not valid1OKFile processed without errors2CorruptEvents were found that were found to be invalidSystem Digital State SetSimilar to digital state sets is the system digital state set. This set is used for all points, regardless of type, to indicate the state of a point at a particular time. For example, if the interface receives bad data from the data source, it writes the system digital state Bad?Input to PI instead of a value. The system digital state set has many unused states that can be used by the interface and other PI clients. Digital States 193-320 are reserved for OSIsoft applications.PointSource The PointSource is a unique, single or multi-character string that is used to identify the PI point as a point that belongs to a particular interface. For example, the string Boiler1 may be used to identify points that belong to the MyInt interface. To implement this, the PointSource attribute would be set to Boiler1 for every PI point that is configured for the MyInt interface. Then, if /ps=Boiler1 is used on the startup command-line of the MyInt interface, the interface will search the PI Point Database upon startup for every PI point that is configured with a PointSource of Boiler1. Before an interface loads a point, the interface usually performs further checks by examining additional PI point attributes to determine whether a particular point is valid for the interface. For additional information, see the /ps parameter. If the PI API version being used is prior to 1.6.x or the PI?Server version is prior to 3.4.370.x, the PointSource is limited to a single character unless the SDK is being used. Case-sensitivity for PointSource AttributeThe PointSource character that is supplied with the /ps command-line parameter is not case sensitive. That is, /ps=P and /ps=p are equivalent. Reserved Point SourcesSeveral subsystems and applications that ship with PI are associated with default PointSource characters. The Totalizer Subsystem uses the PointSource character T, the Alarm Subsystem uses @ for Alarm Tags, G for Group Alarms and Q for SQC Alarm Tags, Random uses R, RampSoak uses 9, and the Performance Equations Subsystem uses C. Do not use these PointSource characters or change the default point source characters for these applications. Also, if a PointSource character is not explicitly defined when creating a PI?point; the point is assigned a default PointSource character of Lab (PI 3). Therefore, it would be confusing to use Lab as the PointSource character for an interface.Note: Do not use a point source character that is already associated with another interface program. However it is acceptable to use the same point source for multiple instances of an interface.PI Point ConfigurationThe PI point is the basic building block for controlling data flow to and from the PI?Server. A single point is configured for each measurement value that needs to be archived. Point AttributesUse the point attributes below to define the PI point configuration for the interface, including specifically what data to transfer.This document does not discuss the attributes that configure UniInt or PI Server processing for a PI point. Specifically, UniInt provides exception reporting and the PI Server provides data compression. Exception reporting and compression are very important aspects of data collection and archiving, which are not discussed in this document.Note: See the UniInt Interface User Manual and PI Server documentation for information on other attributes that are significant to PI point data collection and archiving.TagThe Tag attribute (or tag name) is the name for a point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI documentation uses the terms “tag” and “point” interchangeably.Follow these rules for naming PI points:The name must be unique on the PI Server.The first character must be alphanumeric, the underscore (_), or the percent sign (%).Control characters such as linefeeds or tabs are illegal.The following characters also are illegal: * ’ ? ; { } [ ] | \ ` ' "LengthDepending on the version of the PI API and the PI Server, this interface supports tags whose length is at most 255 or 1023 characters. The following table indicates the maximum length of this attribute for all the different combinations of PI API and PI Server versions. PI APIPI ServerMaximum Length1.6.0.2 or higher3.4.370.x or higher10231.6.0.2 or higherBelow 3.4.370.x255Below 1.6.0.23.4.370.x or higher255Below 1.6.0.2Below 3.4.370.x255If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2, and you want to use a maximum tag length of 1023, you need to enable the PI SDK. See Appendix B for information.PointSourceThe PointSource attribute contains a single, unique character that is used to identify the PI point as a point that belongs to a particular interface. For additional information, see the /ps?command-line parameter and the PointSource chapter.PointTypeTypically, device point types do not need to correspond to PI point types. For example, integer values from a device can be sent to floating-point or digital PI tags. Similarly, a floating-point value from the device can be sent to integer or digital PI tags, although the values will be truncated. For measurement data points (Location2=0), the interface supports float16, float32, float 64, int16, int32, digital point types. For quality points, digital point types are recommended. See the section Digital States for more information on the suggested quality digital set definitions.For alarm points (Location2=1), the interfaces supports only string points.The PointType for the interface specific performance points (Location2= -1) is fixed for each performance counter/status. For a list of the required PointTypes for the performance points, refer to section Interface Specific Performance Points.For more information on the individual PointTypes, see PI Server manuals.Location1Location1 indicates to which copy of the interface the point belongs. The value of this attribute must match the /id command-line parameter.Location2Location2 indicates whether the interface should store the value or the quality of an event.Location2Action-1Store interface specific performance data0Store event values/quality/status (depending on InstrumentTag) 1Store alarm messagesLocation3Location3 is not used by this interface.Location4Location4 is normally used by UniInt based interfaces to specify the scan class that a point belongs to.As this interface only supports unsolicited inputs, all points MUST be configured with Location4=0.Location5Location5 is used to control point debug messages.Location5Point Debug messages0Disabled1EnabledInstrumentTagLengthDepending on the version of the PI API and the PI Server, this interface supports an InstrumentTag attribute whose length is at most 32 or 1023 characters. The following table indicates the maximum length of this attribute for all the different combinations of PI API and PI Server versions. PI APIPI ServerMaximum Length1.6.0.2 or higher3.4.370.x or higher10231.6.0.2 or higherBelow 3.4.370.x32Below 1.6.0.23.4.370.x or higher32Below 1.6.0.2Below 3.4.370.x32If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2, and you want to use a maximum InstrumentTag length of 1023, you need to enable the PI SDK. See Appendix B for information. Measurement Data Points (Location2=0)InstrumentTag is used to specify the Power TG point and field that the interface will use link an event record to the PI point and to specify the type of data to be extracted from the event record. To identify the source of an event within the Power TG system, the buffer data file includes the Point Id (and integer value) and the Point Field Name (string).Once the event record has been matched to the PI point, the interface needs to which field from the event to store and how the data should be formatted. To do this, a keyword is appended after the field name. The interface recognizes the following data type keywordsKeywordData to be storedBlankIf the quality is good then the value will be stored. If the quality is questionable then the value is stored with the PI questionable flag set. If the quality is bad then a system digital will be stored to indicate the cause of the bad value,.VALStore the value regardless of the quality.QUALStore the quality priority (as defined in the data_qualities.ini file).ALARMStore the alarm status (as defined in the TG_ALARM_STATUS digital set).QQSSSSStore the OPC QQSSSS quality field.LIMITStore the OPC limit quality field.SPECIALStore the OPC special quality fieldTo specify this within the InstrumentTag, the interface is expecting the following formatPointId@Field.KeywordFor example:3534@STATEvalue or system digital, depending on the quality5197@ACT_ACC.VALvalue only (ignores quality)7268@VALUEvalue or system digital, depending on the quality7269@VALUE.VALvalue only (ignores quality)7269@VALUE.QUALquality priority846@VALUE.ALARMalarm statusAlarm Message Points (Location2=1) Filter ExpressionInstrumentTag is used to specify the filter to be applied to the alarm messages before the alarm is allowed to be written to the point. This allows alarms to be sorted into various groups, with one PI point for each group.The filter consists of a list of expressions. Each expression consists of a field name, and comparison operator and a value to compare the field against.Field NameOperatorsValuePRIORITYEqual = or ==Not equal != or <>Less than <Less than or equal <=Greater than >Greater than or equal >=NumericAOR_GROUPEqual = or ==Not equal != or <>Wildcard stringENTITYEqual = or ==Not equal != or <>Wildcard stringIf the wildcard string value needs to include space characters then enclose the entire string with quotes (double or single).A wildcard string value supports the following charactersCharacters in patternMatches in string?Any single character*Zero or more characters#Any single digit (0-9)[charlist]Any single character in charlist. By using a hyphen (-) to separate the upper and lower bounds of the range, charlist can specify a range of characters.[!charlist]Any single character that is NOT is charlist.Several field expressions can be combined with either AND or OR. Parenthesis () are not supported. All the expressions are evaluated in the order they appear in the filter expression.For example, if a PI string point is configured with the InstrumentTag PRIORITY<10 AND AOR_GROUP=SUB*then the interface would store all alarms that had a priority value less than 10 and also belonged to the AOR_GROUP starting with the letters SUB.Interface Specific Performance Points (Location2=-1)The InstrumentTag for performance points MUST be empty.ExDescLengthDepending on the version of the PI API and the PI Server, this interface supports an ExDesc attribute whose length is at most 80 or 1023 characters. The following table indicates the maximum length of this attribute for all the different combinations of PI API and PI Server versions. PI APIPI ServerMaximum Length1.6.0.2 or higher3.4.370.x or higher10231.6.0.2 or higherBelow 3.4.370.x80Below 1.6.0.23.4.370.x or higher80Below 1.6.0.2Below 3.4.370.x80If the PI Server version is earlier than 3.4.370.x or the PI API version is earlier than 1.6.0.2, and you want to use a maximum ExDesc length of 1023, you need to enable the PI SDK. See Appendix B for information. Power TG data and quality pointsFor Power TG data or quality points, the ExDesc attribute is used as a comment to store the TG tag name. It is not used by the interface to identify points (that is done with the InstrumentTag attribute), but as a PointId is not very convenient format for people to use, the tag name is included in the PI point configuration to make things easier.Performance Points To allow for monitoring of the performance of the interface and to help with troubleshooting, the interface supports a number of interface specific performance points as well as the standard UniInt performance points. For more information to the configuration of the Performance points see the section Interface Diagnostics Configuration.Scan By default, the Scan attribute has a value of 1, which means that scanning is turned on for the point. Setting the scan attribute to 0 turns scanning off. If the scan attribute is 0 when the interface starts, a message is written to the pipc.log and the tag is not loaded by the interface. There is one exception to the previous statement.If any PI point is removed from the interface while the interface is running (including setting the scan attribute to 0), SCAN OFF will be written to the PI point regardless of the value of the Scan attribute. Two examples of actions that would remove a PI point from an interface are to change the point source or set the scan attribute to 0. If an interface-specific attribute is changed that causes the tag to be rejected by the interface, SCAN OFF will be written to the PI point.ShutdownThe Shutdown attribute is 1 (true) by default. The default behavior of the PI Shutdown subsystem is to write the SHUTDOWN digital state to all PI points when PI is started. The timestamp that is used for the SHUTDOWN events is retrieved from a file that is updated by the Snapshot Subsystem. The timestamp is usually updated every 15 minutes, which means that the timestamp for the SHUTDOWN events will be accurate to within 15?minutes in the event of a power failure. For additional information on shutdown events, refer to PI Server manuals. Note: The SHUTDOWN events that are written by the PI Shutdown subsystem are independent of the SHUTDOWN events that are written by the interface when the /stopstat=Shutdown command-line parameter is specified. SHUTDOWN events can be disabled from being written to PI when PI is restarted by setting the Shutdown attribute to 0 for each point. Alternatively, the default behavior of the PI Shutdown Subsystem can be changed to write SHUTDOWN events only for PI?points that have their Shutdown attribute set to 0. To change the default behavior, edit the \PI\dat\Shutdown.dat file, as discussed in PI Server manuals.Bufserv and PIBufssIt is undesirable to write shutdown events when buffering is being used. Bufserv and PIBufss are utility programs that provide the capability to store and forward events to a PI?Server, allowing continuous data collection when the PI Server is down for maintenance, upgrades, backups, and unexpected failures. That is, when the PI Server is shutdown, Bufserv or PIBufss will continue to collect data for the interface, making it undesirable to write SHUTDOWN events to the PI points for this interface. Disabling Shutdown is recommended when sending data to a Highly Available PI?Server Collective. Refer to the Bufserv or PIBufss manuals for additional information.Startup Command FileCommand-line parameters can begin with a / or with a -. For example, the /ps=M and -ps=M command-line parameters are equivalent.For Windows, command file names have a .bat extension. The Windows continuation character (^) allows for the use of multiple lines for the startup command. The maximum length of each line is 1024 characters (1 kilobyte). The number of parameters is unlimited, and the maximum length of each parameter is 1024 characters.The PI Interface Configuration Utility (PI ICU) provides a tool for configuring the interface startup command file.Configuring the Interface with PI ICUNote: PI ICU requires PI 3.3 or greater.The PI Interface Configuration Utility provides a graphical user interface for configuring PI interfaces. If the interface is configured by the PI ICU, the batch file of the interface (PISIPowerTG.bat) will be maintained by the PI ICU and all configuration changes will be kept in that file and the module database. The procedure below describes the necessary steps for using PI ICU to configure the SIPowerTG interface.From the PI ICU menu, select Interface, then NewWindows Interface Instance from EXE..., and then Browse to the PISIPowerTG.exe executable file. Then, enter values for Host PI System, Point Source, and Interface ID#. A window such as the following results: Interface name as displayed in the ICU (optional) will have PI- pre-pended to this name and it will be the display name in the services menu.Click Add. The following message should appear: Note that in this example the Host PI Server is msltest1. To configure the interface to communicate with a remote PI Server, select Connections…from the PI ICU Interface menu and select the default server. If the remote node is not present in the list of servers, it can be added. Once the interface is added to PI ICU, near the top of the main PI ICU screen, the interface Type should be SIPowerTG. If not, use the drop-down box to change the interface Type to be SIPowerTG.Click on Apply to enable the PI ICU to manage this instance of the SIPowerTG interface.The next step is to make selections in the interface-specific page (that is, “SIPowerTG”) that allows you to enter values for the startup parameters that are particular to the SIPowerTG interface. Since the SIPowerTG interface is a UniInt-based interface, in some cases the user will need to make appropriate selections in the UniInt page. This page allows the user to access UniInt features through the PI ICU and to make changes to the behavior of the interface. To set up the interface as a Windows Service, use the Service page. This page allows configuration of the interface to run as a service as well as to starting and stopping of the interface service. The interface can also be run interactively from the PI ICU. To do that, select Start Interactive on the Interface menu.For more detailed information on how to use the above-mentioned and other PI ICU pages and selections, please refer to the PI Interface Configuration Utility user guide. The next section describes the selections that are available from the SIPowerTG page. Once selections have been made on the PI ICU GUI, press the Apply button in order for PI ICU to make these changes to the interface’s startup file. SIPowerTG Interface PageSince the startup file of the SIPowerTG interface is maintained automatically by the PI ICU, use the SIPowerTG page to configure the startup parameters and do not make changes in the file manually. The following is the description of interface configuration parameters used in the PI ICU Control and corresponding manual parameters.SIPowerTGThe SIPowerTG ICU Control for PI ICU has 2 tabs. A yellow text box indicates that an invalid value has been entered, or that a required value has not been entered.ParametersThe Parameters tab Alarm FileThe Alarm File parameter (/alarm=x) specifies the name of the Siemens message data file that the interface will process to get the alarm messages from the PowerTG system. By default the PowerTG system will put the alarm messages in the file D:\lg\scada\dat\his\msgdata.his.1.PI.dat. The full path to the data should be specified to ensure that the correct directory will be used, regardless of which directory the interface is started from. If the directory that is to contain the file does not exist, then the interface will abort on startup.Data FileThe Alarm File parameter (/data=x) specifies the name of the Siemens meansurement data file that the interface will process to get the data values from the PowerTG system. By default the PowerTG system will put the measurement data files in the file D:\lg\scada\dat\his\measdata.his.1.PI.dat. The full path to the data should be specified to ensure that the correct directory will be used, regardless of which directory the interface is started from. If the directory that is to contain the file does not exist, then the interface will abort on startup.Data Quality Def. FileThe Data Quality Def. File (/qualcodefile=x) specifies the name of the Power TG data qualities definition file. This file is used by the Power TG system to display a quality notation to the operator displays. To enable to PI database to use the same notations, the interface reads the same definition file as the Power TG system. The interface reads the data quality priorities from this file and uses the priorities when processing data quality points (Location2=0, InstrumentTag suffix .QUAL).To ensure that the interface will be checking the correct location, it is recommended that the absolute path to the file is specified.Note: the en_US directory of the above path is the locale of the system. This is likely to be different for systems outside the US. For example, in Mexico the locale is likely to be es_MX.Rename Alarm File ToIf this option is defined (/renamealarm=x), when the interface has finished processing the alarm file, the interface will rename the file to the name specified in the Rename Alarm File To field. This allows multiple interfaces (for a different historian or the same type of interface with a different configuration) to process the same file. The default behavior is to delete the file when it has been processed.Rename Data File ToIf this option is defined (/renamedata=x), when the interface has finished processing the event data file, the interface will rename the file to the name specified in the Rename Data File To field. This allows multiple interfaces (for a different historian or the same type of interface with a different configuration) to process the same file. The default behavior is to delete the file when it has been processed.Process Files only when connectedWhen the "Process Files only when connected" flag is selected (/onlyconnected), the interface will only process files when the connection to the PI server is good. If the connection is lost then the interface will stop processing files.By default the interface will process files regardless of the connection status and if the connection is down then the events sent will be buffered by Bufserv or PIBufss. The default configuration is recommended when sending data to a collective because even though one PI server may not be available, other members of the collectives should be available to receive the events.Enable Power TG FailoverWhen two instances of the interface are running on different Power TG systems and using the Power TG failover mechanism, the UniInt Health Tag ID argument (/uht_id=x) must be specified so that the instances of the interface can have separate UniInt Health points.When the Enable Power TG Failover flag is checked, the ICU control requires a Health Tag ID value to be entered. This value must be unique for each instance of the interface. Typically, use 1 for the primary interface and 2 for the secondary interface. This value is set in the Location3 attribute of the UniInt health points, so that the interface is able to identify which of the health points it need to send values to.Debug ParametersThe Debug tab is provided to allow debug message flags to be set for the interface. When a particular debug flag is set, then messages relating to the flag are logged. The various debug flags can be seen below.For example, if there was a problem with the interface loading a PI point , the "L - Load Tags" debug flag could be set, and then when points were loaded by the interface, detailed debug messages about the points loaded would be logged.Additional ParametersThis section is provided for any additional parameters that the current ICU Control does not support.Note: The UniInt Interface User Manual includes details about other command-line parameters, which may be mand-line ParametersParameterDescription/alarm=filenameRequired for alarm processingSpecifies the name of the buffer alarm file the interface will read the alarm messages from. To ensure that the interface will be checking the correct location, it is recommended that the absolute path to the file is specified.Example: /alarm=D:\lg\scada\dat\his\msgdata.his.1.PI.dat/CacheModeRequired when using disconnected startupDefault: Not DefinedRequired for disconnected startup operation. If defined, the /CacheMode startup parameter indicates that the interface will be configured to utilize the disconnected startup feature./CachePath=pathOptionalDefault: Not DefinedUsed to specify a directory in which to create the point caching files. The directory specified must already exist on the target machine. By default, the files are created in the same location as the interface executable.If the path contains any spaces, enclose the path in quotes.Examples:/CachePath=D:\PIPC\Interfaces\CacheFiles/CachePath=D:/PIPC/Interfaces/CacheFiles/CachePath=D:/PIPC/Interfaces/CacheFiles/Examples with space in path name:/CachePath="D:\Program Files\PIPC\MyFiles"/CachePath="D:/Program Files/PIPC/MyFiles"/CachePath="D:/Program Files/PIPC/MyFiles/"/CacheSynch=#OptionalDefault: 250 msNOTE: Care must be taken when modifying this parameter. This value must be less than the smallest scan class period defined with the /f parameter. If the value of the /CacheSynch parameter is greater than the scan class value, input scans will be missed while the point cache file is being synchronized.The optional /CacheSynch=# startup parameter specifies the time slice period in milliseconds (ms) allocated by UniInt for synchronizing the interface point cache file with the PI?Server. By default, the interface will synchronize the point cache if running in the disconnected startup mode. UniInt allocates a maximum of #?ms each pass through the control loop synchronizing the interface point cache until the file is completely synchronized. Synchronization of the point cache file can be disabled by setting the value /CacheSynch=0. The minimum synchronization period when cache synchronization is enabled is 50ms Whereas, the maximum synchronization period is 3000ms (3s). Period values of 1 to 49 will be changed by the interface to the minimum of 50ms and values greater than 3000 will be set to the maximum interval value of 3000ms. Default: 250 msRange: {0, 50 – 3000} time in millisecondsExample: /CacheSynch=50 (use a 50ms interval) /CacheSynch=3000 (use a 3s interval) /CacheSynch=0 (do not synchronize the cache)/data=filenameRequired for data processingSpecifies the name of the buffer data file the interface will read the events from. To ensure that the interface will be checking the correct location, it is recommended that the absolute path to the file is specified.Example:/data=D:\lg\scada\dat\his\measdata.his.1.PI.dat/debug=xOptionalThe debug parameter specifies a list of debug message types that can be logged to help with troubleshooting the interface. The types areI – InitializationL – Load tagsF – File handlingD – Power TG data processingA – Power TG alarm processingP – PI point processingR – Removing tagsN – New Tag added after initial point loadingQ – Interface quittingX – All of the above (equivalent to ILFDAPRQ)V – verbose (show more detail)The messages will be logged in the pipc.log file.For example, to log messages to show the raw values of the events from the data file and the values sent to PI, use the parameter /debug=DP/ec=#OptionalThe first instance of the /ec parameter on the command-line is used to specify a counter number, #, for an I/O Rate point. If the # is not specified, then the default event counter is 1. Also, if the /ec parameter is not specified at all, there is still a default event counter of 1 associated with the interface. If there is an I/O Rate point that is associated with an event counter of 1, every interface that is running without /ec=# explicitly defined will write to the same I/O Rate point. Either explicitly define an event counter other than 1 for each instance of the interface or do not associate any I/O Rate points with event counter 1. Configuration of I/O Rate points is discussed in the section called I/O Rate Point.For interfaces that run on Windows nodes, subsequent instances of the /ec?parameter may be used by specific interfaces to keep track of various input or output operations. Subsequent instances of the /ec parameter can be of the form /ec*, where * is any ASCII character sequence. For example, /ecinput=10, /ecoutput=11, and /ec=12 are legitimate choices for the second, third, and fourth event counter strings./host=host:portRequired for Windows and UNIXThe /host parameter is used to specify the PI Home node. Host is the IP address of the PI Server node or the domain name of the PI Server node. Port is the port number for TCP/IP communication. The port is always 5450. It is recommended to explicitly define the host and port on the command-line with the /host parameter. Nevertheless, if either the host or port is not specified, the interface will attempt to use defaults.Examples:The interface is running on a interface node, the domain name of the PI?home node is Marvin, and the IP address of Marvin is 206.79.198.30. Valid /host parameters would be:/host=marvin/host=marvin:5450/host=206.79.198.30/host=206.79.198.30:5450/id=xHighly RecommendedThe /id parameter is used to specify the interface identifier. The interface identifier is a string that is no longer than 9 characters in length. UniInt concatenates this string to the header that is used to identify error messages as belonging to a particular interface. See Appendix A Error and Informational Messages for more information.UniInt always uses the /id parameter in the fashion described above. This interface also uses the /id parameter to identify a particular interface instance number that corresponds to an integer value that is assigned to one of the Location code point attributes, most frequently Location1. For this interface, use only numeric characters in the identifier. For example,/id=1/onlyconnectedOptionalWhen the /onlyconnected parameter given, the interface will only process files when the connection to the PI server is good. If the connection is lost then the interface will stop processing files.By default the interface will process files regardless of the connection status and if the connection is down then the events sent will be buffered by bufserv. The default configuration is recommended when sending data to a collective because even though one PI server may not be available, other members of the collectives should be available to receive the events./ps=xRequiredThe /ps parameter specifies the point source for the interface. X is not case sensitive and can be any multiple character string. For example, /ps=P and /ps=p are equivalent. The length of X is limited to 100 characters by UniInt. X can contain any character except ‘*’ and ‘?’.The point source that is assigned with the /ps parameter corresponds to the PointSource attribute of individual PI Points. The interface will attempt to load only those PI points with the appropriate point source. If the PI API version being used is prior to 1.6.x or the PI?Server version is prior to 3.4.370.x, the PointSource is limited to a single character unless the SDK is being used./qualcodefile=xRequired for data quality code processingSpecifies the name of the Power TG data qualities definition file. The interface reads the data quality priorities from this file and uses the priorities when processing data quality points (Location2=0, InstrumentTag suffix .QUAL).To ensure that the interface will be checking the correct location, it is recommended that the absolute path to the file is specified.Example: /qualcodefile=D:\lg\scada\fg\en_US\data_qualities.iniNote: the en_US directory of the above path is the locale of the system. This is likely to be different for systems outside the US. For example, in Mexico the locale is likely to be es_MX./renamealarm=xOptionalSpecifies the filename that the interface to rename the alarm file to, after it has finished processing it. This is to allow other applications to process the same file. If there is already a file existing with the same name, the interface will wait until the other file has been removed.By default, the alarm file is deleted after the interface has finished processing it./renamedata=xOptionalSpecifies the filename that the interface to rename the data file to, after it has finished processing it. This is to allow other applications to process the same file. If there is already a file existing with the same name, the interface will wait until the other file has been removed.By default, the data file is deleted after the interface has finished processing it./stopstat=digstateor/stopstat/stopstat only is equivalent to/stopstat="Intf Shut"OptionalDefault = no digital state written at shutdown.If /stopstat=digstate is present on the command line, then the digital state, digstate, will be written to each PI point when the interface is stopped. For a PI3 Server, digstate must be in the system digital state table. . UniInt will use the first occurrence of digstate found in the table.If the /stopstat parameter is present on the startup command line, then the digital?state Intf Shut will be written to each PI point when the interface is stopped. If neither /stopstat nor /stopstat=digstate is specified on the command line, then no digital states will be written when the interface is shut down.Note: When using interfaces in a failover or redundant configuration, the -stopstat parameter should not be used as it would interrupt the data streams for the points, when no data was actually lost.Examples:/stopstat=shutdown/stopstat="Intf Shut"The entire digstate value must be enclosed within double quotes when there is a space in digstate./uht_id=#OptionalRequired if any type of failover other than UniInt Failover Phase 1 or 2 is supported.The /uht_id=# command-line parameter is used to specify a unique ID for interfaces that are run in a redundant mode without using the UniInt failover mechanism. There are several OSIsoft interfaces that are UniInt based and implement their own version of failover. In order for health tag(s) to be configured to monitor a single copy of the Interface, an additional parameter is required. If the /uht_id=# is specified; only health tags with a Location3 value equal to # will be loaded.Sample PISIPowerTG.bat FileThe following is an example file:REM=======================================================================REMREM PISIPowerTG.batREMREM Sample startup file for the PI Interface for Siemens Spectrum Power TGREMREM=======================================================================REM REM OSIsoft strongly recommends using PI ICU to modify startup files.REMREM Sample command lineREM .\PISIPowerTG ^ /host=XXXXXX:5450 ^ /ps=TG ^ /id=1 ^ /alarm=D:\lg\scada\dat\his\msgdata.his.1.PI.dat ^ /data=D:\lg\scada\dat\his\measdata.his.1.PI.dat ^ /qualcodefile=D:\lg\scada\fg\en_US\data_qualities.iniREMREM End of PISIPowerTG.bat FileInterface Specific FailoverIntroductionThe 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 stations that can send data to PI, only one of these will be publishing the input data files for its 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 an input data file is available, there are no issues with having both instances of the interface running at the same time.The diagram below shows the architecture used when using redundant Power TG machines to send data to a high-availability PI server collective.The problem with the above mechanism is that when the secondary station takes over, it can publish an input data file with up to 30 minutes of data so that the data that failed to be sent by the primary station will be sent by the secondary. But some of data would have already been sent to PI via the primary interface before the primary failure occurred. This overlap in data ensures that there is not gap in the data on the PI servers, but this overlap 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, if an interface has not been processing files for some time (either on startup or it has been on standby) and it receives a data file, the interface will read the snapshot value of the performance PI point containing the timestamp of the latest event. The interface will then process the data file normally, but it will discard the events that are older than the timestamp 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 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). 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.Because it is necessary to inform Power TG users when the connection to a PI server is lost, the BufStat utility can be used to check the status of the connections, and generate the necessary alarm messages with the Power TG system.Point Configuration for FailoverPoint ConfigurationBecause the interface can process both measurement data files and alarm message file, the interface supports two sets of performance points, one for each file type.It is not necessary to specifically configure the interface for failover. However, by configuring a X_LATEST_TIMESTAMP performance point (where X is DATA or ALARM), it will help minimize the amount the out-of-order data sent to PI. When the interface sees a file to process, but it hasn’t processed a file for more than a minute, it assumes that it has been on standby and it becoming the active interface. If a X_LATEST_TIMESTAMP performance point has been configured and the connection to the PI server is good, then the interface will read the value of the performance point and use that time as a cut-off for the events it reads from the file. Any event with a timestamp prior to the cut-off time will be dropped.If the X_LATEST_TIMESTAMP point is not configured or it is not able to read the value of the timestamp then the interface will send all the events to PI. This will mean some out-of-order events may be sent to PI, but this is not a major issue. The PI server can handle these, although the events will not be compressed and it can affect the performance of the PI server. For this reason, if the interfaces are run with failover, it is recommended that a X_LATEST_TIMESTAMP performance point is configured.For more information on configuring interface-specific performance points, see section Interface Specific Performance Points.When using failover, both instances of the interface will be writing to the same set of interface specific performance points. This is not a problem, because only one instance of the interface should be processing files at any one time. However, if there is a problem with the Power TG failover mechanism, it is possible for both interfaces to write different values at the same time into the performance points, which could cause some confusion.When using failover interface with the UniInt performance points, each instance of the interface should be configured with its own set of UniInt performance points. The points use location3 and the UniInt -uht_id= argument to differentiate the two sets of points. See the UniInt Interface User Manual for more information.Interface Node ClockWindows Make sure that the time and time zone settings on the computer are correct. To confirm, run the Date/Time applet located in the Windows Control Panel. If the locale where the interface node resides observes Daylight Saving Time, check the Automatically adjust clock for daylight saving changes box. For example,In addition, make sure that the TZ environment variable is not defined. All of the currently defined environment variables can be viewed by opening a Command Prompt window and typing set. That is,C:> setConfirm that TZ is not in the resulting list. If it is, run the System applet of the Control Panel, click the Environment Variables button under the Advanced tab, and remove TZ from the list of environment variables.SecurityWindows and UNIXThe PI Firewall Database and the PI Proxy Database must be configured so that the interface is allowed to write data to the PI Server. See “Modifying the Firewall Database” and “Modifying the Proxy Database” in the PI Server manuals.Note that the Trust Database, which is maintained by the Base Subsystem, replaces the Proxy Database used prior to PI version 3.3. The Trust Database maintains all the functionality of the proxy mechanism while being more secure.See “Trust Login Security” in the chapter “Managing Security” of the PI Server System Management Guide.If the interface cannot write data to the PI Server because it has insufficient privileges, a 10401 error will be reported in the pipc.log file. If the interface cannot send data to a PI2 Server, it writes a -999 error. See the section Appendix A: Error and Informational Messages for additional information on error messaging.PI Server v3.3 and HigherSecurity configuration using piconfigFor PI Server v3.3 and higher, the following example demonstrates how to edit the PI Trust table:C:\PI\adm> piconfig@table pitrust@mode create@istr Trust,IPAddr,NetMask,PIUsera_trust_name,192.168.100.11,255.255.255.255,piadmin@quitFor the above,Trust: An arbitrary name for the trust table entry; in the above example,a_trust_nameIPAddr: the IP Address of the computer running the interface; in the above example,192.168.100.11NetMask: the network mask; 255.255.255.255 specifies an exact match with IPAddrPIUser: the PI user the interface to be entrusted as; piadmin is usually an appropriate userSecurity Configuring using Trust EditorThe Trust Editor plug-in for PI System Management Tools 3.x may also be used to edit the PI Trust table.See the PI System Management chapter in the PI Server manual for more details on security configuration.PI Server v3.2For PI Server v3.2, the following example demonstrates how to edit the PI Proxy table:C:\PI\adm> piconfig@table pi_gen,piproxy@mode create@istr host,proxyaccountpiapimachine,piadmin@quitIn place of piapimachine, put the name of the interface node as it is seen by the PI Server.Starting / Stopping the Interface on Windows This section describes starting and stopping the interface once it has been installed as a service. See the UniInt Interface User Manual to run the interface interactively.Starting Interface as a ServiceIf the interface was installed as service, it can be started from PI ICU, the Services control panel or with the command:PISIPowerTG.exe /startTo start the interface service with PI ICU, use the button on the PI ICU toolbar.A message will inform the user of the status of the interface service. Even if the message indicates that the service has started successfully, double check through the Services control panel applet. Services may terminate immediately after startup for a variety of reasons, and one typical reason is that the service is not able to find the command-line parameters in the associated .bat file. Verify that the root name of the .bat file and the .exe?file are the same, and that the .bat file and the .exe file are in the same directory. Further troubleshooting of services might require consulting the pipc.log file, Windows Event Viewer, or other sources of log messages. See the section Appendix A: Error and Informational Messages for additional information.Stopping Interface Running as a ServiceIf the interface was installed as service, it can be stopped at any time from PI ICU, the Services control panel or with the command:PISIPowerTG.exe /stopThe service can be removed by:PISIPowerTG.exe /removeTo stop the interface service with PI ICU, use the button on the PI ICU toolbar.BufferingBuffering refers to an interface node’s ability to temporarily store the data that interfaces collect and to forward these data to the appropriate PI Servers. OSIsoft strongly recommends that you enable buffering on your interface nodes. Otherwise, if the interface node stops communicating with the PI Server, you lose the data that your interfaces collect. The PI SDK installation kit installs two buffering applications: the PI Buffer Subsystem (PIBufss) and the PI API Buffer Server (Bufserv). PIBufss and Bufserv are mutually exclusive; that is, on a particular computer, you can run only one of them at any given time. If you have PI Servers that are part of a PI collective, PIBufss supports n-way buffering. N-way buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI collective. (Bufserv also supports n-way buffering, but OSIsoft recommends that you run PIBufss instead.)Note: The BufStat utility is only compatible with bufserv buffering service. Because of the different mechanisms used internally, BufStat is not compatible with the PIBufss buffering service.Which Buffering Application to UseYou should use PIBufss whenever possible because it offers better throughput than Bufserv. In addition, if the interfaces on an interface node are sending data to a PI collective, PIBufss guarantees identical data in the archive records of all the PI Servers that are part of that collective. You can use PIBufss only under the following conditions:the PI Server version is at least 3.4.375.x; andall of the interfaces running on the interface node send data to the same PI Server or to the same PI collective.If any of the following scenarios apply, you must use Bufserv:the PI Server version is earlier than 3.4.375.x; orthe interface node runs multiple interfaces, and these interfaces send data to multiple PI Servers that are not part of a single PI collective. If an interface node runs multiple interfaces, and these interfaces send data to two or more PI collectives, then neither PIBufss nor Bufserv is appropriate. The reason is that PIBufss and Bufserv can buffer data only to a single collective. If you need to buffer to more than one PI collective, you need to use two or more interface nodes to run your interfaces.It is technically possible to run Bufserv on the PI Server Node. However, OSIsoft does not recommend this configuration.How Buffering WorksA complete technical description of PIBufss and Bufserv is beyond the scope of this document. However, the following paragraphs provide some insights on how buffering works.When an interface node has buffering enabled, the buffering application (PIBufss or Bufserv) connects to the PI Server. It also creates shared memory storage.When an interface program makes a PI API function call that writes data to the PI Server (for example, pisn_sendexceptionqx()), the PI API checks whether buffering is enabled. If it is, these data writing functions do not send the interface data to the PI Server. Instead, they write the data to the shared memory storage that the buffering application created. The buffering application (either Bufserv or PIBufss) in turnreads the data in shared memory, andif a connection to the PI Server exists, sends the data to the PI Server; orif there is no connection to the PI Server, continues to store the data in shared memory (if shared memory storage is available) or writes the data to disk (if shared memory storage is full).When the buffering application re-establishes connection to the PI Server, it writes to the PI Server the interface data contained in both shared memory storage and disk.(Before sending data to the PI Server, PIBufss performs further tasks such as data validation and data compression, but the description of these tasks is beyond the scope of this document.)When PIBufss writes interface data to disk, it writes to multiple files. The names of these buffering files are PIBUFQ_*.DAT. When Bufserv writes interface data to disk, it writes to a single file. The name of its buffering file is APIBUF.DAT. As a previous paragraph indicates, PIBufss and Bufserv create shared memory storage at startup. These memory buffers must be large enough to accommodate the data that an interface collects during a single scan. Otherwise, the interface may fail to write all its collected data to the memory buffers, resulting in data loss. The buffering configuration section of this chapter provides guidelines for sizing these memory buffers.When buffering is enabled, it affects the entire interface node. That is, you do not have a scenario whereby the buffering application buffers data for one interface running on an interface node but not for another interface running on the same interface node.Buffering and PI Server SecurityAfter you enable buffering, it is the buffering application?–?and?not?the?interface?program?–?that writes data to the PI Server. If the PI Server’s trust table contains a trust entry that allows all applications on an interface node to write data, then the buffering application is able write data to the PI Server.However, if the PI Server contains an interface-specific PI Trust entry that allows a particular interface program to write data, you must have a PI Trust entry specific to buffering. The following are the appropriate entries for the Application Name field of a PI Trust entry:Buffering ApplicationApplication Name field for PI TrustPI Buffer SubsystemPIBufss.exePI API Buffer ServerAPIBE (if the PI API is using 4 character process names)APIBUF (if the PI API is using 8 character process names)To use a process name greater than 4 characters in length for a trust application name, use the LONGAPPNAME=1 in the PIClient.ini file.Enabling Buffering on an Interface Node with the ICUThe ICU allows you to select either PIBufss or Bufserv as the buffering application for your interface node. Run the ICU and select Tools > Buffering.Choose Buffer TypeTo select PIBufss as the buffering application, choose Enable buffering with PI Buffer Subsystem.To select Bufserv as the buffering application, choose Enable buffering with API Buffer Server. If a warning message such as the following appears, click Yes.Buffering SettingsThere are a number of settings that affect the operation of PIBufss and Bufserv. The Buffering Settings section allows you to set these parameters. If you do not enter values for these parameters, PIBufss and Bufserv use default values.PIBufssFor PIBufss, the paragraphs below describe the settings that may require user intervention. Please contact OSIsoft Technical Support for assistance in further optimizing these and all remaining settings.Primary and Secondary Memory Buffer Size (Bytes)This is a key parameter for buffering performance. The sum of these two memory buffer sizes must be large enough to accommodate the data that an interface collects during a single scan. A typical event with a Float32 point type requires about 25 bytes. If an interface writes data to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a result, the size of each memory buffer should be 62,500 bytes.The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these two memory buffer sizes should be increased to the maximum of 2000000 for the best buffering performance.Send rate (milliseconds)Send rate is the time in milliseconds that PIBufss waits between sending up to the Maximum transfer objects (described below) to the PI Server. The default value is 100. The valid range is 0 to 2,000,000.Maximum transfer objectsMaximum transfer objects is the maximum number of events that PIBufss sends between each Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.Event Queue File Size (Mbytes)This is the size of the event queue files. PIBufss stores the buffered data to these files. The default value is 32. The range is 8 to 131072 (8 to 128 Gbytes). Please see the section entitled "Queue File Sizing" in the PIBufss.chm file for details on how to appropriately size the event queue files.Event Queue PathThis is the location of the event queue file. The default value is [PIHOME]\DAT.For optimal performance and reliability, OSIsoft recommends that you place the PIBufss event queue files on a different drive/controller from the system drive and the drive with the Windows paging file. (By default, these two drives are the same.)BufservFor Bufserv, the paragraphs below describe the settings that may require user intervention. Please contact OSIsoft Technical Support for assistance in further optimizing these and all remaining settings.Maximum buffer file size (KB)This is the maximum size of the buffer file ([PIHOME]\DAT\APIBUF.DAT). When Bufserv cannot communicate with the PI Server, it writes and appends data to this file. When the buffer file reaches this maximum size, Bufserv discards data.The default value is 2,000,000 KB, which is about 2 GB. The range is from 1 to 2,000,000.Primary and Secondary Memory Buffer Size (Bytes)This is a key parameter for buffering performance. The sum of these two memory buffer sizes must be large enough to accommodate the data that an interface collects during a single scan. A typical event with a Float32 point type requires about 25 bytes. If an interface writes data to 5,000 points, it can potentially send 125,000 bytes (25 * 5000) of data in one scan. As a result, the size of each memory buffer should be 62,500 bytes.The default value of these memory buffers is 32,768 bytes. OSIsoft recommends that these two memory buffer sizes should be increased to the maximum of 2000000 for the best buffering performance.Send rate (milliseconds)Send rate is the time in milliseconds that Bufserv waits between sending up to the Maximum transfer objects (described below) to the PI Server. The default value is 100. The valid range is 0 to 2,000,000.Maximum transfer objectsMax transfer objects is the maximum number of events that Bufserv sends between each Send rate pause. The default value is 500. The valid range is 1 to 2,000,000.Buffered ServersThe Buffered Servers section allows you to define the PI Servers or PI collective that the buffering application writes data.PIBufssPIBufss buffers data only to a single PI Server or a PI collective. Select the PI Server or the PI collective from the Buffering to collective/server drop down list box.The following screen shows that PIBufss is configured to write data to a standalone PI Server named starlight. Notice that the Replicate data to all collective member nodes check box is disabled because this PI Server is not part of a collective. (PIBufss automatically detects whether a PI Server is part of a collective.)The following screen shows that PIBufss is configured to write data to a PI collective named admiral. By default, PIBufss replicates data to all collective members. That is, it provides n-way buffering.You can override this option by not checking the Replicate data to all collective member nodes check box. Then, uncheck (or check) the PI Server collective members as desired.BufservBufserv buffers data to a standalone PI Server, or to multiple standalone PI Servers. (If you want to buffer to multiple PI Servers that are part of a PI collective, you should use PIBufss.)If the PI Server to which you want Bufserv to buffer data is not in the Server list, enter its name in the Add a server box and click the Add Server button. This PI Server name must be identical to the API Hostname entry:The following screen shows that Bufserv is configured to write to a standalone PI Server named etamp390. You use this configuration when all the interfaces on the interface node write data to etamp390. The following screen shows that Bufserv is configured to write to two standalone PI Servers, one named etamp390 and the other one named starlight. You use this configuration when some of the interfaces on the interface node write data to etamp390 and some write to starlight.Installing Buffering as a ServiceBoth the PIBufss and Bufserv applications run as a Service.PI Buffer Subsystem ServiceUse the PI Buffer Subsystem Service page to configure PIBufss as a Service. This page also allows you to start and stop the PIBufss service.PIBufss does not require the logon rights of the local administrator account. It is sufficient to use the LocalSystem account instead. Although the screen below shows asterisks for the LocalSystem password, this account does not have a password.API Buffer Server ServiceUse the API Buffer Server Service page to configure Bufserv as a Service. This page also allows you to start and stop the Bufserv ServiceBufserv version 1.6 and later does not require the logon rights of the local administrator account. It is sufficient to use the LocalSystem account instead. Although the screen below shows asterisks for the LocalSystem password, this account does not have a password.Interface Diagnostics ConfigurationThe PI Point Configuration chapter provides information on building PI points for collecting data from the device. This chapter describes the configuration of points related to interface diagnostics.Note: The procedure for configuring interface diagnostics is not specific to this interface. Thus, for simplicity, the instructions and screenshots that follow refer to an interface named ModbusE. Some of the points that follow refer to a “performance summary interval”. This interval is 8 hours by default. You can change this parameter via the Scan performance summary box in the UniInt – Debug parameter category page:Interface Specific Performance PointsTo monitor the status and performance of the interface as it processes the files, the interface supports a number of performance PI points that are specific to this interface. Because the interface is able to process two different types of input file, there are two sets of performance points. One set of points for the measurement data and another for the alarm messages.To indicate that a PI point is an interface-specific performance point, Location2 must be set to -1. To identify the performance value to be stored in the point, the interface checks the ExDesc attribute for the a specific keyword. The following is a list of the keywords, the expected PI PointType and a description of the value.ExDesc KeywordPointTypeDescriptionDATA_LATEST_TIMESTAMPFloat64Timestamp of the latest event found in the data file.DATA_EVENTS_FOUNDInt32Total number of events found in the data file.DATA_EVENTS_SENTInt32Total number of events sent to the PI system from the data file.DATA_FILE_STATUSDigitalStatus to indicate whether the data file was processed cleanly or whether errors were found. See the section File Status State Set for the digital set definition.DATA_TIME_TAKENFloat32Number of milliseconds the interface took to process the data file.ALARM_LATEST_TIMESTAMPFloat64Timestamp of the latest event found in the alarm file.ALARM_EVENTS_FOUNDInt32Total number of events found in the alarm file.ALARM_EVENTS_SENTInt32Total number of events sent to the PI system from the alarm file.ALARM_FILE_STATUSDigitalStatus to indicate whether the alarm file was processed cleanly or whether errors were found. See the section File Status State Set for the digital set definition.ALARM_TIME_TAKENFloat32Number of milliseconds the interface took to process the alarm file.If the PI point does not have the same PointType as those listed, the PI point will be rejected by the interface.Note: The xxxx_LATEST_TIMESTAMP performance points are important when the interface is running in a redundant configuration, as it will help to reduce the overlapping data when the failover occurs.Sample Interface Specific Performance PointsThe file SIPowerTG_Interface_Health_Tags.csv including in the install kit contains a set of typical Interface Specific Health Points that can be used to monitor the performance of the interface. Scan Class Performance PointsThis interface does not support Scan Class Performance Points. This is because the interface does not use scan classes. All points have unsolicited updates.Performance Counters PointsWhen running as a Service or interactively, this interface exposes performance data via Windows Performance Counters. Such data include items like:the amount of time that the interface has been running;the number of points the interface has added to its point list;the number of tags that are currently updating among othersThere are two types or instances of Performance Counters that can be collected and stored in PI Points. The first is (_Total) which is a total for the Performance Counter since the interface instance was started. The other is for individual scan classes (Scan Class x) where x is a particular scan class defined for the interface instance that is being monitored.OSIsoft’s PI Performance Monitor interface is capable of reading these performance values and writing them to PI points. Please see the Performance Monitor Interface for more information.If there is no PI Performance Monitor Interface registered with the ICU in the Module Database for the PI Server the interface is sending its data to, you cannot use the ICU to create any interface instance’s Performance Counters Points:After installing the PI Performance Monitor Interface as a service, select this interface instance from the Interface drop-down list, then click Performance Counters in the parameter categories pane, and rightclick on the row containing the Performance Counters Point you wish to create. This will open the shortcut menu:Click Create to create the Performance Counters Point for that particular row. Click Create All to create all the Performance Counters Points listed which have a status of Not Created.To see the current values (snapshots) of the created Performance Counters Points, rightclick on any row and select Refresh Snapshots.Note: The PI Performance Monitor Interface – and not this interface – is responsible for updating the values for the Performance Counters Points in PI. So, make sure that the PI Performance Monitor Interface is running correctly.Performance CountersIn the following lists of Performance Counters the naming convention used will be:“PerformanceCounterName” (.PerformanceCounterPointSuffix) The tagname created by the ICU for each Performance Counter point is based on the setting found under the Tools Options Naming Conventions Performance Counter Points. The default for this is “sy.perf.[machine].[if service] followed by the Performance Counter Point suffix.Note: This interface does not use scan classes. All points have unsolicited updates. For some counters, scan class zero (0) is used for unsolicited point updates.Performance Counters for both (_Total) and (Scan Class x) “Point Count” (.point_count)A .point_count Performance Counters Point is available for each scan class of this interface as well as an "(_Total)" for the interface instance. The .point_count Performance Counters Point indicates the number of PI Points per scan class or the total number for the interface instance. This point is similar to the Health Point [UI_SCPOINTCOUNT] for scan classes and [UI_POINTCOUNT] for totals.The ICU uses a naming convention such that the tag containing "(Scan Class 1)" (for example, "sy.perf.etamp390.E1(Scan?Class?1).point_count") refers to scan class 1, “(Scan Class 2)” refers to scan class 2, and so on. The tag containing "(_Total)" refers to the sum of all scan classes.“Scheduled Scans: % Missed” (.sched_scans_%missed)A .sched_scans_%missed Performance Counters Point is available for each scan class of this interface as well as an "(_Total)" for the interface instance.The .sched_scans_%missed Performance Counters Point indicates the percentage of scans the interface missed per scan class or the total number missed for all scan classes since startup. A missed scan occurs if the interface performs the scan one second later than scheduled.The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for example, "sy.perf.etamp390.E1(Scan Class 1).sched_scans_%missed") refers to scan class 1, “(Scan Class 2)” refers to scan class 2, and so on. The tag containing “(_Total)” refers to the sum of all scan classes.“Scheduled Scans: % Skipped” (.sched_scans_%skipped)A .sched_scans_%skipped Performance Counters Point is available for each scan class of this interface as well as an "(_Total)" for the interface instance. The .sched_scans_%skipped Performance Counters Point indicates the percentage of scans the interface skipped per scan class or the total number skipped for all scan classes since startup. A skipped scan is a scan that occurs at least one scan period after its scheduled time. This point is similar to the [UI_SCSKIPPED] Health Point.The ICU uses a naming convention such that the tag containing "(Scan Class 1)" (for example, "sy.perf.etamp390.E1(Scan Class 1).sched_scans_%skipped") refers to scan class 1, "(Scan Class 2)" refers to scan class 2, and so on. The tag containing "(_Total)" refers to the sum of all scan classes.“Scheduled Scans: Scan count this interval” (.sched_scans_this_interval)A .sched_scans_this_interval Performance Counters Point is available for each scan class of this interface as well as an "(_Total)" for the interface instance. The .sched_scans_this_interval Performance Counters Point indicates the number of scans that the interface performed per performance summary interval for the scan class or the total number of scans performed for all scan classes during the summary interval. This point is similar to the [UI_SCSCANCOUNT] Health Point.The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for example, “sy.perf.etamp390.E1(Scan?Class?1).sched_scans_this_interval” refers to scan class 1, “(Scan Class 2)” refers to scan class 2, and so on. The tag containing “(_Total)” refers to the sum of all scan classes.Performance Counters for (_Total) only“Device Actual Connections” (.Device_Actual_Connections)The .Device_Actual_Connections Performance Counters Point stores the actual number of foreign devices currently connected and working properly out of the expected number of foreign device connections to the interface. This value will always be less than or equal to the Device Expected Connections counter.“Device Expected Connections” (.Device_Expected_Connections)The .Device_Expected_Connections Performance Counters Point stores the total number of foreign device connections for the interface. This is the expected number of foreign device connections configured that should be working properly at runtime. If the interface can only communicate with 1 foreign device then the value of this counter will always be one. If the interface can support multiple foreign device connections then this is the total number of expected working connections configured for this interface.“Device Status” (.Device_Status)The .Device_Status Performance Counters Point stores communication information about the interface and the connection to the foreign device(s). The value of this counter is based on the expected connections, actual connections and value of the /PercentUp command line option. If the device status is good then the value is ‘0’. If the device status is bad then the value is ‘1’. If the interface only supports connecting to 1 foreign device then the /PercentUp command line value does not change the results of the calculation. If for example the interface can connect to 10 devices and 5 are currently working then the value of the /PercentUp command line parameter is applied to determine the Device Status. If the value of the /PercentUp command line parameter is set to 50 and at least 5 devices are working then the DeviceStatus will remain good (that is, have a value of zero).“Failover Status” (.Failover_Status)The .Failover_Status Performance Counters Point stores the failover state of the interface when configured for UniInt failover. The value of the counter will be ‘0’ when the interface is running as the primary interface in the failover configuration. If the interface is running in backup mode then the value of the counter will be '1'.“Interface up-time (seconds)” (.up_time)The .up_time Performance Counters Point indicates the amount of time (in seconds) that this interface has been running. At startup the value of the counter is zero. The value will continue to increment until it reaches the maximum value for an unsigned integer. Once it reaches this value then it will start back over at zero. “IO Rate (events/second)” (.io_rates)The .io_rates Performance Counters Point indicates the rate (in event per second) at which this interface writes data to its input tags. (As of UniInt 4.5.0.x and later this performance counters point will no longer be available.)“Log file message count” (.log_file_msg_count)The .log_file_msg_count Performance Counters Point indicates the number of messages that the interface has written to the log file. This point is similar to the [UI_MSGCOUNT] Health Point.“PI Status” (PI_Status)The .PI_Status Performance Counters Point stores communication information about the interface and the connection to the PI Server. If the interface is properly communicating with the PI Server then the value of the counter is ‘0’. If the communication to the PI Server goes down for any reason then the value of the counter will be ‘1’. Once the interface is properly communicating with the PI Server again then the value will change back to ‘0’.“Points added to the interface” (.pts_added_to_interface)The .pts_added_to_interface Performance Counter Point indicates the number of points the interface has added to its point list. This does not include the number of points configured at startup. This is the number of points added to the interface after the interface has finished a successful startup. “Points edited in the interface”(.pts_edited_in_interface)The .pts_edited_in_interface Performance Counters Point indicates the number of point edits the interface has detected. The interface detects edits for those points whose PointSource attribute matches the /ps= parameter and whose Location1 attribute matches the /id= parameter of the interface.“Points Good” (.Points_Good)The .Points_Good Performance Counters Point is the number of points that have sent a good current value to PI. A good value is defined as any value that is not a system digital state value. A point can either be Good, In Error, or Stale. The total of Points Good, Points In Error, and Points State will equal the Point Count. There is one exception to this rule. At startup of an interface, the Stale timeout must elapse before the point will be added to the Stale Counter. Therefore the interface must be up and running for at least 10 minutes for all tags to belong to a particular Counter.“Points In Error” (.Points_In_Error)The .Points_In_Error Performance Counters Point indicates the number of points that have sent a current value to PI that is a system digital state value. Once a point is in the In Error count it will remain in the In Error count until the point receives a new, good value. Points in Error do not transition to the Stale Counter. Only good points become stale. “Points removed from the interface” (.pts_removed_from_interface)The .pts_removed_from_interface Performance Counters Point indicates the number of points that have been removed from the interface configuration. A point can be removed from the interface when one of the point attributes is updated and the point is no longer a part of the interface configuration. For example, changing the PointSource, Location1, or Scan attribute can cause the tag to no longer be a part of the interface configuration.“Points Stale 10(min)” (.Points_Stale_10min)The .Points_Stale_10min Performance Counters Point indicates the number of good points that have not received a new value in the last 10 minutes. If a point is Good, then it will remain in the good list until the Stale timeout elapses. At this time if the point has not received a new value within the Stale Period then the point will move from the Good count to the Stale count. Only points that are Good can become Stale. If the point is in the In Error count then it will remain in the In Error count until the error clears. As stated above, the total count of Points Good, Points In Error, and Points Stale will match the Point Count for the interface.“Points Stale 30(min)” (.Points_Stale_30min)The .Points_Stale_30min Performance Counters Point indicates the number of points that have not received a new value in the last 30 minutes. For a point to be in the Stale 30 minute count it must also be a part of the Stale 10 minute count.“Points Stale 60(min)” (.Points_Stale_60min)The .Points_Stale_60min Performance Counters Point indicates the number of points that have not received a new value in the last 60 minutes. For a point to be in the Stale 60 minute count it must also be a part of the Stale 10 minute and 30 minute count.“Points Stale 240(min)” (.Points_Stale_240min)The .Points_Stale_240min Performance Counters Point indicates the number of points that have not received a new value in the last 240 minutes. For a point to be in the Stale 240 minute count it must also be a part of the Stale 10 minute, 30 minute and 60 minute count.Performance Counters for (Scan Class x) only“Device Scan Time (milliseconds)” (.Device_Scan_Time)A .Device_Scan_Time Performance Counter Point is available for each scan class of this interface. The .Device_Scan_Time Performance Counters Point indicates the number of milliseconds the interface takes to read the data from the foreign device and package the data to send to PI. This counter does not include the amount of time to send the data to PI. This point is similar to the [UI_SCINDEVSCANTIME] Health Point.The ICU uses a naming convention such that the tag containing “(Scan Class 1)” (for example, "sy.perf.etamp390.E1?(Scan?Class?1).device_scan?_time") refers to scan class 1, “(Scan Class 2) refers to scan class 2, and so on.“Scan Time (milliseconds)” (.scan_time)A .scan_time Performance Counter Point is available for each scan class of this interface. The .scan_time Performance Counter Point indicates the number of milliseconds the interface takes to both read the data from the device and send the data to PI. This point is similar to the [UI_SCINSCANTIME] Health Point.The ICU uses a naming convention such that the tag containing “(Scan?Class?1)” (for example, "sy.perf.etamp390.E1(Scan?Class?1).scan_time") refers to scan class 1, “(Scan Class 2)” refers to scan class 2, and so on.Interface Health Monitoring PointsInterface Health Monitoring Points provide information about the health of this interface. To use the ICU to configure these points, select this interface from the Interface dropdown list and click Health Points from the parameter category pane:Rightclick the row for a particular Health Point to display the shortcut menu:Click Create to create the Health Point for that particular row. Click Create All to create all the Health Points.To see the current values (snapshots) of the Health Points, rightclick and select Refresh Snapshots.For some of the Health Points described subsequently, the interface updates their values at each performance summary interval (typically, 8 hours).Note: This interface does not use scan classes. All points have unsolicited updates. For some health points, scan class zero (0) is used for unsolicited point updates.Note: This interface does not support event-triggered input points or output points. Therefore, some of the counters below will not be updated.[UI_HEARTBEAT]The [UI_HEARTBEAT] Health Point indicates whether the interface is currently running. The value of this point is an integer that increments continuously from 1 to 15. After reaching 15, the value resets to 1. The fastest scan class frequency determines the frequency at which the interface updates this point:Fastest Scan FrequencyUpdate frequencyLess than 1 second1 secondBetween 1 and 60 seconds, inclusiveScan frequencyMore than 60 seconds60 secondsIf the value of the [UI_HEARTBEAT] Health Point is not changing, then this interface is in an unresponsive state.As this interface does not use scan classes, it will use the update frequency of 1 second.[UI_DEVSTAT]The Health tag with a string point type and the attribute ExDesc = [UI_DEVSTAT], is used to represent the status of the interface. The possible values for this string point are:“1 | Starting” – The Interface remains in this state until it has successfully collected data from its first scan.“Good” – The interface is able to collect data. A value of “Good” does not mean that all tags are receiving good values, but it is a good indication that there are no hardware or network problems.“4 | Intf Shutdown” – The Interface has shut down.The Interface updates this point whenever the interface is started or stopped.[UI_SCINFO]The [UI_SCINFO] Health Point provides scan class information. The value of this point is a string that indicates the number of scan classes;the update frequency of the [UI_HEARTBEAT] Health Point; andthe scan class frequenciesAn example value for the [UI_SCINFO] Health Point is:3 | 5 | 5 | 60 | 120The interface updates the value of this point at startup and at each performance summary interval.[UI_IORATE]The [UI_IORATE] Health Point indicates the sum ofthe number of scan-based input values the interface collects before it performs exception reporting; andthe number of event-based input values the interface collects before it performs exception reporting; andthe number of values that the interface writes to output tags that have a SourceTag.The interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The value of this [UI_IORATE] Health Point may be zero. A stale timestamp for this point indicates that this interface has stopped collecting data.[UI_MSGCOUNT]The [UI_MSGCOUNT] Health Point tracks the number of messages that the interface has written to the log file since start-up. In general, a large number for this point indicates that the interface is encountering problems. You should investigate the cause of these problems by looking in log messages.The interface updates the value of this point every 60 seconds. While the interface is running, the value of this point never decreases.[UI_POINTCOUNT]The [UI_POINTCOUNT] Health Point counts number of PI tags loaded by the interface. This count includes all input, output, and triggered input tags. This count does NOT include any Interface Health tags or performance points.The interface updates the value of this point at startup, on change, and at shutdown.[UI_OUTPUTRATE]After performing an output to the device, this interface writes the output value to the output tag if the tag has a SourceTag. The [UI_OUTPUTRATE] Health Point tracks the number of these values. If there are no output tags for this interface, it writes the System Digital State No Result to this Health Point.The interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The interface resets the value of this point to zero at each performance summary interval.This interface does not support output points, so this health point is not required.[UI_OUTPUTBVRATE]The [UI_OUTPUTBVRATE] Health Point tracks the number of System Digital State values that the interface writes to output tags that have a SourceTag. If there are no output tags for this interface, it writes the System Digital State No Result to this Health Point.The interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The interface resets the value of this point to zero at each performance summary interval.This interface does not support output points and so this health point is not required.[UI_TRIGGERRATE]The [UI_TRIGGERRATE] Health Point tracks the number of values that the interface writes to event-based input tags. If there are no event-based input tags for this interface, it writes the System Digital State No Result to this Health Point.The interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The interface resets the value of this point to zero at each performance summary interval.This interface does not support event-based input tags, so this health point is not required.[UI_TRIGGERBVRATE]The [UI_TRIGGERBVRATE] Health Point tracks the number of System Digital State values that the interface writes to event-based input tags. If there are no event-based input tags for this interface, it writes the System Digital State No Result to this Health Point.The interface updates this point at the same frequency as the [UI_HEARTBEAT] point. The interface resets the value of this point to zero at each performance summary interval.This interface does not support event-based input tags, so this health point is not required.[UI_SCIORATE]You can create a [UI_SCIORATE] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix “.sc1” (for example, sy.st.etamp390.E1.Scan Class IO Rate.sc1) refers to scan class 1, “.sc2” refers to scan class 2, and so on.A particular scan class’s [UI_SCIORATE] point indicates the number of values that the interface has collected. If the current value of this point is between zero and the corresponding [UI_SCPOINTCOUNT] point, inclusive, then the interface executed the scan successfully. If a [UI_SCIORATE] point stops updating, then this condition indicates that an error has occurred and the tags for the scan class are no longer receiving new data.The interface updates the value of a [UI_SCIORATE] point after the completion of the associated scan.The ICU allows you to create the point with the suffix “.sc0” and this point will contain the IO rate for all points. Scan class zero (0) is used for unsolicited points, as all points on this interface are unsolicited.[UI_SCBVRATE]You can create a [UI_SCBVRATE] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Bad Value Rate.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.A particular scan class’s [UI_SCBVRATE] point indicates the number System Digital State values that the interface has collected.The interface updates the value of a [UI_SCBVRATE] point after the completion of the associated scan.The ICU allows you to create the point with the suffix “.sc0” and this point will contain the bad value rate for all points. Scan class zero (0) is used for unsolicited points, as all points on this interface are unsolicited.[UI_SCSCANCOUNT]You can create a [UI_SCSCANCOUNT] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Scan Count.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.A particular scan class's [UI_ SCSCANCOUNT] point tracks the number of scans that the interface has performed.The interface updates the value of this point at the completion of the associated scan. The interface resets the value to zero at each performance summary interval.Although there is no "Scan Class 0", the ICU allows you to create the point with the suffix ".sc0". This point indicates the total number of scans the interface has performed for all of its Scan Classes.[UI_SCSKIPPED]You can create a [UI_SCSKIPPED] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Scans Skipped.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.A particular scan class’s [UI_SCSKIPPED] point tracks the number of scans that the interface was not able to perform before the scan time elapsed and before the interface performed the next scheduled scan.The interface updates the value of this point each time it skips a scan. The value represents the total number of skipped scans since the previous performance summary interval. The interface resets the value of this point to zero at each performance summary interval.As all the points for the interface are unsolicited, there are no skipped scans and so this health point is not required.[UI_SCPOINTCOUNT]You can create a [UI_SCPOINTCOUNT] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Point Count.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.This Health Point monitors the number of tags in a scan class.The interface updates a [UI_SCPOINTCOUNT] Health Point when it performs the associated scan.The ICU allows you to create the point with the suffix ".sc0", and this point will contain the point count for all the points.[UI_SCINSCANTIME]You can create a [UI_SCINSCANTIME] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Scan Time.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.A particular scan class's [UI_ SCINSCANTIME] point represents the amount of time (in milliseconds) the interface takes to read data from the device, fill in the values for the tags, and send the values to the PI Server.The interface updates the value of this point at the completion of the associated scan.This health point is not supported for unsolicited updates and so is not required for this interface.[UI_SCINDEVSCANTIME]You can create a [UI_SCINDEVSCANTIME] Health Point for each scan class in this interface. The ICU uses a tag naming convention such that the suffix ".sc1" (for example, sy.st.etamp390.E1.Scan Class Device Scan Time.sc1) refers to scan class 1, ".sc2" refers to scan class 2, and so on.A particular scan class's [UI_ SCINDEVSCANTIME] point represents the amount of time (in milliseconds) the interface takes to read data from the device and fill in the values for the tags.The value of a [UI_ SCINDEVSCANTIME] point is a fraction of the corresponding [UI_SCINSCANTIME] point value. You can use these numbers to determine the percentage of time the interface spends communicating with the device compared with the percentage of time communicating with the PI Server.If the [UI_SCSKIPPED] value is increasing, the [UI_SCINDEVSCANTIME] points along with the [UI_SCINSCANTIME] points can help identify where the delay is occurring: whether the reason is communication with the device, communication with the PI Server, or elsewhere.The interface updates the value of this point at the completion of the associated scan. This health point is not supported for unsolicited updates and so is not required for this interface.Failover configurations with UniInt Health PointsWhen using failover interface with the UniInt performance points, each instance of the interface should be configured with its own set of UniInt performance points. The points use location3 and the -uht_id= argument to differentiate the two sets of points. See the UniInt Interface User Manual for more information.Sample UniInt Health PointsThe file SIPowerTG_UniInt_Health_Tags.csv including in the install kit contains a set of typical UniInt Health Points that can be used to monitor the performance of the interface. Two sets of points are included to support a pair of failover interfaces.I/O Rate PointAn I/O Rate point measures the rate at which the interface writes data to its input tags. The value of an I/O Rate point represents a 10-minute average of the total number of values per minute that the interface sends to the PI Server. When the interface starts, it writes 0 to the I/O Rate point. After running for ten minutes, the interface writes the I/O Rate value. The interface continues to write a value every 10 minutes. When the interface stops, it writes 0.The ICU allows you to create one I/O Rate point for each copy of this interface. Select this interface from the Interface drop-down list, click IO Rate in the parameter category pane, and check Enable IORates for this interface. As the preceding picture shows, the ICU suggests an Event Counter number and a Tagname for the I/O Rate Point. Click the Save button to save the settings and create the I/O Rate point. Click the Apply button to apply the changes to this copy of the interface.You need to restart the interface in order for it to write a value to the newly created I/O Rate point. Restart the interface by clicking the Restart button:(The reason you need to restart the interface is that the PointSource attribute of an I/O Rate point is Lab.)To confirm that the interface recognizes the I/O Rate Point, look in the pipc.log for a message such as:PI-ModBus 1> IORATE: tag sy.io.etamp390.ModbusE1 configured.To see the I/O Rate point’s current value (snapshot), click the Refresh snapshot button:Enable IORates for this InterfaceThe Enable IORates for this interface check box enables or disables I/O Rates for the current interface. To disable I/O Rates for the selected interface, uncheck this box. To enable I/O Rates for the selected interface, check this box.Event CounterThe Event Counter correlates a tag specified in the iorates.dat file with this copy of the interface. The command-line equivalent is /ec=x, where x is the same number that is assigned to a tag name in the iorates.dat file.TagnameThe tag name listed in the Tagname box is the name of the I/O Rate tag.Tag StatusThe Tag Status box indicates whether the I/O Rate tag exists in PI. The possible states are:Created – This status indicates that the tag exist in PINot Created – This status indicates that the tag does not yet exist in PIDeleted – This status indicates that the tag has just been deletedUnknown – This status indicates that the PI ICU is not able to access the PI ServerIn FileThe In File box indicates whether the I/O Rate tag listed in the tag name and the event counter is in the IORates.dat file. The possible states are:Yes – This status indicates that the tag name and event counter are in the IORates.dat fileNo – This status indicates that the tag name and event counter are not in the IORates.dat fileSnapshotThe Snapshot column holds the snapshot value of the I/O Rate tag, if the I/O Rate tag exists in PI. The Snapshot box is updated when the IORate page is selected, and when the interface is first loaded.Create/SaveCreate the suggested I/O Rate tag with the tag name indicated in the Tagname box. Or Save any changes for the tag name indicated in the Tagname box.DeleteDelete the I/O Rate tag listed in the Tagname box.RenameAllow the user to specify a new name for the I/O Rate tag listed in the Tagname box.Add to FileAdd the tag to the IORates.dat file with the event counter listed in the Event Counter box.SearchAllow the user to search the PI Server for a previously defined I/O Rate tag.Interface Status PointThe PI Interface Status Utility (ISU) alerts you when an interface is not currently writing data to the PI Server. This situation commonly occurs ifthe monitored interface is running on an interface node, but the interface node cannot communicate with the PI Server; orthe monitored interface is not running, but it failed to write at shutdown a system state such as Intf Shut.The ISU works by periodically looking at the timestamp of a Watchdog Tag. The Watchdog Tag is a tag whose value a monitored interface (such as this interface) frequently updates. The Watchdog Tag has its ExcDev, ExcMin, and ExcMax point attributes set to 0. So, a non-changing timestamp for the Watchdog Tag indicates that the monitored interface is not writing data.Please see the Interface Status Utility Interface for complete information on using the ISU. PI Interface Status Utility Interface runs only on a PI Server Node.If you have used the ICU to configure the PI Interface Status Utility Interface on the PI Server Node, the ICU allows you to create the appropriate ISU point. Select this interface from the Interface drop-down list and click Interface Status in the parameter category pane. Rightclick on the ISU tag definition window to open the shortcut menu:Click Create to create the ISU tag. Use the Tag Search button to select a Watchdog Tag. (Recall that the Watchdog Tag is one of the points for which this interface collects data.) Select a Scan frequency from the drop-down list box. This Scan frequency is the interval at which the ISU monitors the Watchdog Tag. For optimal performance, choose a Scan frequency that is less frequent than the majority of the scan rates for this interface’s points. For example, if this interface scans most of its points every 30 seconds, choose a Scan frequency of 60 seconds. If this interface scans most of its points every second, choose a Scan frequency of 10 seconds.If the Tag Status indicates that the ISU tag is Incorrect, rightclick to open the shortcut menu and select Correct.Note: The PI Interface Status Utility Interface – and not this interface – is responsible for updating the ISU tag. So, make sure that the PI Interface Status Utility Interface is running correctly.Error and Informational MessagesA string NameID is pre-pended to error messages written to the message log. Name is a nonconfigurable identifier that is no longer than 9 characters. ID is a configurable identifier that is no longer than 9 characters and is specified using the /id parameter on the startup command-line.Message LogsThe location of the message log depends upon the platform on which the interface is running. See the UniInt Interface User Manual for more information.Messages are written to [PIHOME]\dat\pipc.log at the following times.When the interface starts many informational messages are written to the log. These include the version of the interface, the version of UniInt, the commandline parameters used, and the number of points.As the interface loads points, messages are sent to the log if there are any problems with the configuration of the points.If the UniInt /dbUniInt parameter is found in the command-line, then various informational messages are written to the log file.MessagesThe following are the error messages that can be generated by the interface, including the description of the cause of the error and a way of correcting the error.StartupMessageInvalid debug option [?] - ABORTINGCauseA debug option given in the -debug= argument is not recognized by the interface.ResolutionCheck that all the debug options listed are valid.MessageUnable to locate directory "????" - ABORTINGCauseThe directory specified by either the -data= or -alarm= argument was not found.ResolutionVerify that the directory that will contain the either the data input file or alarm input file exists.Message"????" is not a directory - ABORTINGCauseThe directory specified by either the -data= or -alarm= argument was located, but it not a valid directory. ResolutionVerify that the directory that will contain the either the data input file or alarm input file exists.MessageNo read/write permission for data directory "????" - ABORTINGCauseThe directory specified by either the -data= or -alarm= argument was located , but the user running the interface does not have read/write permissions for the directory. Because the interface needs to be able to read and delete the files from the directory, the interface must have read/write permissions for the directory.ResolutionVerify that the interface is being run by the correct user, and that user has read/write permissions for the directory.MessageCannot rename data file when data file not defined - ABORTINGCauseThe -renamedata parameter has been specified, but the -data argument has not. It is meaningless to rename the data file when the data file has not been set. ResolutionEither remove the -renamedata parameter or set the -data parameter, depending on the requirements for the interface.MessageCannot rename alarm file when alarm file not defined - ABORTINGCauseThe -renamealarm parameter has been specified, but the -alarm argument has not. It is meaningless to rename the alarm file when the alarm file has not been set. ResolutionEither remove the -renamealarm parameter or set the -alarm parameter, depending on the requirements for the interface.MessageNeither -data= or -alarm= arguments specifiedAt least one must be specified - ABORTINGCauseThe interface can process either data input files or alarm input files or both. The interface will not run if neither of these arguments is defined.ResolutionAdd either a -data or -alarm parameter, or both.Message-data= and -alarm= must not refer to the same file - ABORTINGCauseThe -data and -alarm arguments refer to the same file. As the files have different formats, they cannot be the same file. ResolutionCorrect either the -data or -alarm argument.Loading PI pointsMessagePITag ?????? (?) - Interface does not support periodic scan pointsAll data points must have Location4=0CauseThe interface processes input files when a file is available, so all the point updates are unsolicited. It is not able to periodically scan points and so all the points must have Location4=0. This attribute is used by UniInt to define the scan class, and scan classes should not be defined for this interface.ResolutionEdit the PI point to set the Location4 attribute to zero (0).MessagePITag ?????? (?) - Unable to allocate dev_structCauseThe interface was not able to allocate memory to store the configuration of the given point.ResolutionFree up memory on the interface node and restart the interface.MessagePITag ?????? (?) - Invalid interface-specific performance pointExDesc keyword is emptyCauseAn interface-specific performance point (Location2=-1) has an empty ExDesc attribute. ResolutionEdit the PI point to include the required performance value keyword in the ExDesc. See Interface Specific Performance Points for a list of valid keywords.MessagePITag ?????? (?) - Invalid interface-specific performance pointUnrecognized ExDesc keyword "???"CauseThe keyword in the ExDesc of an interface-specific performance point (Location2=-1) does not match an of the valid keywords. ResolutionEdit the PI point to include the required performance value keyword in the ExDesc. See Interface Specific Performance Points for a list of valid keywords.MessagePITag ?????? (?) - Invalid interface-specific performance pointPointType mismatch for the given ExDesc keywordCauseThe interface will only accept an interface-specific performance point (Location2=-1) if the PointType of the point matches that of the given performance value.ResolutionCheck to ensure that the PointType is the same as those listed in the Interface Specific Performance Points section for the given keyword.MessagePITag ?????? (?) - Invalid PI PointType for a measurement data pointCauseA measurement data point (Location2=0) PointType can be float64, float32, float16, int32, int16 or digital. It cannot be a string type.ResolutionCheck that the PI point is configured with a valid PointType for a measurement data point.MessagePITag ?????? (?) - Invalid InstrumentTag for data pointInstrumentTag is emptyCauseA measurement data point (Location2=0) must have the InstrumentTag defined so that the interface will know which Power TG point value to store in the PI point. ResolutionEnsure that the InstrumentTag for the point has been properly defined.MessagePITag ?????? (?) - Invalid InstrumentTag attribute "???"Must be in the format MEASID@FIELD.TYPE where MEASID is an integer valueCauseA measurement data point (Location2=0) must have the InstrumentTag defined with the format MEASID@FIELD.TYPE, where the MEASID is an integer value and matches the Power TG point id of the required point.ResolutionEnsure that the InstrumentTag for the point has been properly defined.MessagePITag ?????? (?) - Invalid InstrumentTag attribute "???"Must be in the format MEASID@FIELD.TYPE where FIELD is NOT blankCauseA measurement data point (Location2=0) must have the InstrumentTag defined with the format MEASID@FIELD.TYPE, where the FIELD is the name of the field required from the Power TG point. ResolutionEnsure that the InstrumentTag for the point has been properly defined. The interface is not able to validate the field name, other than making sure it is not blank, so care must be taken to ensure that the correct field name is used.MessagePITag ?????? (?) - Invalid InstrumentTag attribute "???"Unrecognized TYPE "???"CauseA measurement data point (Location2=0) must have the InstrumentTag defined with the format MEASID@FIELD.TYPE. The .TYPE is optional, but if defined it must match the valid keyword types given in the InstrumentTag section of the manual.ResolutionEnsure that the InstrumentTag for the point has been properly defined.MessagePITag ?????? (?) - Invalid .QUAL typeQuality code definitions are not definedCauseQuality code points (InstrumentTag ends with .QUAL) can only be used with the quality code definitions have been loaded from the data_qualities.ini file.ResolutionCheck that the -qualcodefile= argument has been properly defined and that the quality codes were loaded when the interface was started.MessagePITag ?????? (?) - Invalid digital set for quality prioritiesDigital set must have at least ?? states to store the defined quality prioritiesCauseQuality code points (InstrumentTag ends with .QUAL) must have a digital set defined that has at least the number of states as the highest priority defined in the data_qualitities.ini file.ResolutionCheck the digital set assigned to the point and compare the digital set with the contents of the data_qualitities.ini file and that the -qualcodefile= argument has been properly.MessagePITag ?????? (?) - Invalid PointType for an alarm PI pointan alarm point MUST be a string PI pointCauseAn alarm point (Location2=1) must have a string PointType.ResolutionCheck the configuration of the PI point.MessagePITag ?????? (?) - Unable to parse filter expression from InstrumentTagCauseAn alarm point (Location2=1) can use a filter to limit the alarm messages it will sort. The interface has been unable to parse the filter expression, which is configured in the InstrumentTag attribute.ResolutionCheck the configuration of the point. Refer to the Point Attribute - InstrumentTag section for more information of the filter expression syntax.MessagePITag ?????? (?) - Invalid value for Location2-1=perf, 0=data, 1=alarmCauseThe value of Location2 is not valid.ResolutionCheck the configuration of the PI point and ensure that Location2 is valid. Refer to the Point Attribute - Location2 section for a list of valid values.Data File ProcessingMessageUnable to remove input file xxxxx - ABORTINGerrno=? - ???????????????CauseThe interface failed to remove the file after processing and has aborted. ResolutionUse the system error message to find the cause. It may be a permissions problem, so check the credentials of the user running the interface and the permissions of the input file.MessageUnable to rename xxxxx to yyyyyyyyyy already exists - Will retry every 2 secondsCauseUnable to rename the current input file because the previous file still exists. This is probably caused by the downstream process not having finished processing the file itself.ResolutionCheck that the downstream process that should be removing the file is running correctly. The interface will stop at this point and not process any more files until the previous file has been removed.MessageUnable to rename xxxxx to yyyyyerrno=? - ?????????????Will attempt to delete yyyyyCauseUnable to rename the current input file. The previous file does not exist, but some other error is causing the rename to fail. ResolutionThe interface will delete the current file instead of renaming so that processing can continue.MessageInput data file invalid (does not start with 0x01 0x02)CauseThe measurement data input file is not valid. All data input files must start with the bytes 0x01 0x02. The interface will reject any data input files that do not start with these 2 bytes.ResolutionCheck that the interface is reading the correct file defined by the -data parameter. Use the DumpInputFile utility to check the contents of the file.MessageTG EVENT ?? > INVALID > ???????????????????????CauseThe interface found an error while validating an event from the data input file. This could be caused by a file corruption. The output of the event data should give an indication of the problem. ResolutionUse the DumpInputFile utility to check the contents of the file against the event logged by the interface.MessageTG EVENT ?? > INVALID > ???????????????????????Event timestamp too far into the futureCauseThe interface found an event with a timestamp that was too far into the future to be valid. ResolutionThis could be caused by incorrectly configured time zones, or if the clocks within the system have drifted by more than 5 minutes.MessageForced to exit before data file had finished processingCauseThe interface has been asked to stop while it was processing a data input file. This is only ever likely to be seen if the interface is stuck in a loop while processing the file or the input file is very large.ResolutionIf the input file was not large, then keep a copy of the input file and the current point configuration and contact OSIsoft Tech Support so that the problem can be reproduced.Alarm File ProcessingMessageInput alarm file invalid (does not start with 0x03 0x04)CauseThe alarm input file is not valid. All data input files must start with the bytes 0x03 0x04. The interface will reject any alarm input files that do not start with these 2 bytes. ResolutionCheck that the interface is reading the correct file defined by the -alarm parameter.MessageTG ALARM ?? > INVALID > ???????????????????????CauseThe interface found an error while validating an alarm message from the alarm input file. This could be caused by a file corruption. The output of the alarm message should give an indication of the problem. ResolutionUse the DumpAlarmFile utility to check the contents of the file against the alarm message logged by the interface.MessageTG ALARM ?? > INVALID > ???????????????????????Event timestamp too far into the futureCauseThe interface found an alarm message with a timestamp that was too far into the future to be valid. ResolutionThis could be caused by incorrectly configured time zones, or if the clocks within the system have drifted by more than 5 minutes.MessageForced to exit before alarm file had finished processingCauseThe interface has been asked to stop while it was processing an alarm input file. This is only ever likely to be seen if the interface is stuck in a loop while processing the file or the input file is very large.ResolutionIf the input file was not large, then keep a copy of the input file and the current point configuration and contact OSIsoft Tech Support so that the problem can be reproduced.Getting Latest TimestampThe following error messages can only be generated when the interface is attempting to read the LATEST_TIMESTAMP performance point. It does read the point value, so that it can minimize the number of out-of-order events it sends to PI. The interface should only attempt to read the point value when the interface is starting or when the interface has been in standby (has not been receiving input files to process) and is going active.Note: If there are any problems with reading the LATEST_TIMESTAMP point, the interface will default to sending all the events in the input file. This may result in more out-of-orders events being sent to PI. As the out-of-order events should only occur when the interface is going from standby to active, it would not happen often and the PI server is able to handle a few out-of-order events.MessageNo LATEST_TIMESTAMP point configured, so all events in the file will be sent to PICauseIf no LATEST_TIMESTAMP point has been configured then the interface will not be able to minimize the number of out-of-order sent to PI. All events in the file will be sent.ResolutionTo reduce the chance of Out-Of-Order events, configure LATEST_TIMESTAMP Performance PI points.MessageNot connected to PI, so unable to read latest timestamp to reduce OOO eventsCauseIf the interface does not have a connection to the PI server, it will not attempt to read the current timestamp value from the LATEST_TIMESTAMP performance point, because the read will fail.ResolutionN/AMessageReading LATEST_TIMESTAMP point. pisn_getsnapshotx(??) returned ??????CauseThe interface got an error when attempting to read the LATEST_TIMESTAMP performance point. The PI error appended to the message should give an indication of the cause.ResolutionUse the PI error message to resolve the pisn_getsnapshotx() error.MessageLATEST_TIMESTAMP point returned istat=???, so all events in the file will be sent to PICauseThe interface was able to read the value of the LATEST_TIMESTAMP point, but it contained a system digital state rather than a valid timestamp. Therefore, all the events in the input file will be sent to PI.ResolutionCheck the LATEST_TIMESTAMP PI point is being updated correctly.System Errors and PI ErrorsSystem errors are associated with positive error numbers. Errors related to PI are associated with negative error numbers. Error Descriptions on Windows and UNIX Descriptions of system and PI errors can be obtained with the PISDKUtility , or with the pidiag utilityWindows:%PIHOME%\adm\pidiag /e error_numberPI SDK OptionsTo access the PI SDK settings for this interface, select this interface from the Interface drop-down list and click UniInt – PI SDK in the parameter category pane.Disable PI SDKSelect Disable PI SDK to tell the interface not to use the PI SDK. If you want to run the interface in disconnected startup mode, you must choose this option.The command line equivalent for this option is /pisdk=0.Use the Interface’s default settingThis selection has no effect on whether the interface uses the PI SDK. However, you must not choose this option if you want to run the interface in disconnected startup mode.Enable PI SDKSelect Enable PI SDK to tell the interface to use the PI SDK. Choose this option if the PI Server version is earlier than 3.4.370.x or the PI API is earlier than 1.6.0.2, and you want to use extended lengths for the Tag, Descriptor, ExDesc, InstrumentTag, or PointSource point attributes. The maximum lengths for these attributes are:AttributeEnable the Interface to use the PI SDKPI Server earlier than?3.4.370.x or PI API earlier than 1.6.0.2, without the use of the PI SDKTag1023255Descriptor102326ExDesc102380InstrumentTag102332PointSource10231However, if you want to run the interface in disconnected startup mode, you must not choose this option.The command line equivalent for this option is /pisdk=1.Event Data File StructureThe 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.OffsetLengthDescription04Point ID (integer)49Field Name (string)134Type (integer)1716UTC Timestamp (SQL_TIMESTAMP structure)334Milliseconds timestamp (integer)374Value (IEEE single precision float)418Point Attribute / Quality flags (2 x 4 byte integers)499Source (string)Binary values are in are little endian format.Alarm Message File StructureThe 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.OffsetLengthDescription016UTC Timestamp (SQL_TIMESTAMP structure)164Sequence number (integer)204Priority (integer)249AOR Group (string)339Source (string)424Entity field length in bytes (integer)46EntLenEntity name (string46+EntLen4Message field length in bytes (integer)50+EntLenMsgLenAlarm MessageBinary 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.Setting up a PI Archive on the Power TG SystemPI Server DefinitionThe 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:LongnameThis is the name that will be presented to the Power TG operator in alarm messages and status display for this server.RTDB NameThis 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\<rtdb-name>” where the “<rtdb-name>” portion of the path is substituted for this name.AOR GroupThis 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.Alarm PriorityThis the priority at which alarms relating to the status of the archiving will be puterThis is the name of the computer or collective used for the PI database.InstanceThis is the “Point Source” name used in the PI database. If not specified, “TG” is used.Database TypeChoose “PI” for a PI database.DatabaseIf 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:bufserv:piserver1,piserver2That 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 IDThis 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.Point Collection DefinitionThe second tab of the Data Warehouse form defines the collection of data from the Power TG system for storage into the archive server.Each collection is defined as an “Archive Type” that defines the Power TG system from which the data are collected and the server to which they are stored.To define a new archive type, you click the “New Archive Definition” button at the top right of the form. A dialog box will appear where you define the name of the archive type and its source TG system and destination archive server. There can be as many archive types as needed to define the collection of data.The collection frequency of a set of data is defined by the fields Period, Offset, Delay, Save Changes Only and Force Interval. You can get the specific details of the scheduling from the SDB’s help but there are essentially two collection types:PeriodicThis is the collection when the “Period” field has a non-zero value defined indicating the interval, in seconds, between collection of the data values. The “Offset” and “Delay” values indicate when relative to the beginning of a clock hour the collection is performed and the timestamp that is stored with the values.SpontaneousThis is the collection type when the “Period” field is blank or zero and the “Save Changes Only” box is checked. In this case, changes in value or quality are sent to the archive system as soon as they are detected by the Power TG system.In both cases, the “Force Interval” specifies an interval, in seconds, where the values will be sent to the archive server regardless of change of value or quality.The “Measurement List” field defines the Power TG measurements that will be collected on the schedule defined by this archive type. Clicking on the “Edit Measurement List” button to the right of this field opens a form where measurements can be added to or removed from the list.The “Field List” field defines a list of the attributes that will be collected from the measurement objects in the Power TG database. If left blank, the default attributes of “VALUE” (the current value) for analog measurements, “STATE” (the current state) for status measurements and “DELT_ACC” (the change in value in the most recent sample interval) for accumulators are used. If different or additional attributes are to be archived, a custom list can be created by clicking on the “Edit Field List” to the right of this field.The “Special Field List” field defines a list of values to be extracted from the Power TG database that are not necessarily associated with station measurements. These can reference any numeric field in the Power TG database using its fully qualified Table/Record/Entry/Field (TREF) string. Knowledge of the Power TG real time database is necessary to define these references.For a PI database, there are the following fields presented on the form:PI Exception (%)This specifies the exception reporting threshold in percent of full range as default for all values in the archive type. For station analog measurements, this can be overridden by a definition in the “Data Processing” tab of the analog definition.PI Compression (%)This specifies the compression change threshold in percent of full range as default for all values in the archive type. For station analog measurements, this can be overridden by a definition in the “Data Processing” tab of the analog definition.For all values except analog current values, the range is assumed to be 1000 and the zero value is 0.0. For analogs, the range can be explicitly defined on the “Data Processing” tab or, if that is blank, it is calculated as the first of reasonability limits, telemetry scale values or alarm limits that are defined. If none of the above are defined, the range of the analog value is defaulted to 2000 with a zero value of -1000. If a value is specified in the measurement list of more than one archive type, the lowest value of the exception and compression percentages is used.There are also a set of check boxes on the archive type definition form for PI collections do define additional tags that will be created to store data qualities and other attributes in addition to the primary value. The “primary” value is the default attribute as defines above for analog, status or accumulator data and any value defined by the “Special Field List”. It is useful to define the special fields in a separate archive type if the data quality attributes are to be created. The data quality is only supplied with a special field if the entry in the real time database from which it is collected contains a telemetry failure (TELEM_F) attribute.These check boxes are:Create PI Tags for Base OPC QualityThis option causes an additional tag to be created in the PI database for all primary fields containing the base quality values as defined in the Power TG archiving system. These qualities are expressed as a value in the form QQSSSS where “QQ” represents the summary quality of 0=BAD, 1=Uncertain and 3=Good. The SSSS portion of the value indicates the additional most significant details of the summary quality. The generated tag has the syntax “<entity-name>@OPCQQSSSS” where “<entity-name>” is the entity name of the primary tag. This is a Digital tag using the state set “TG_QUAL_QQSSSS”.Create PI Tags for Limit OPC QualityThis option causes an additional tag to be created in the PI database for the limit portion of the Power TG archive quality for analog value tags. This tag name uses the syntax “<entity-name>@OPC_LL”. This tag indicates the limit conditions of the analogs as a Digital tag using the state set “TG_QUAL_LIMIT”.Create PI Tags for Special QualityThis option causes an additional tag to be created in the PI database for all primary fields containing the special quality values as defined in the Power TG archiving system. These qualities represent the most significant of the “in control”, “alarm inhibit”, etc. qualities. This tag uses the syntax “<entity-name>@OPC_SPCL” and is a Digital tag using the state set “TG_QUAL_SPECIAL”.Create PI Tags for Analog StateThis option causes an additional tag to be created in the PI database for the analog limit state for all analog value tags. This tag name uses the syntax “<entity-name>@AALRM_STATUS”. This tag indicates the limit conditions of the analogs as a Digital tag using the state set “TG_ALARM_STATUS”.Create PI Tags for Quality SymbolThis option causes an additional tag to be created in the PI database for all primary fields containing a digital value indicating the data quality symbol for the point as displayed on the Power TG user interface. The tag name uses the syntax “<entity-name>@DATA_QUALITY” and is a Digital tag using the state set “TG_DATA_QUALITY”.Installing Data from the SDB for a PI ArchiveTo implement changes defined in the SDB, these changes must be “installed” to the Power TG servers and to the PI server. When station points are added or deleted, these are installed to the TG real time database using the “Power TG Host” tab of the SDB Database Installation form.If there are changes in the data to be collected into the PI system, that is installed to the PI server and TG archive system on the TG host servers using the “Data Warehouse” tab if the SDB Database Installation form. To perform this install, choose the name of the PI database on this tab and click the Install button. This will cause a new CSV file to be generated for the Automatic Point Synchronization process to update the tags in the PI database. This may take several minutes after the SDB installation completes before these updates are reflected in the PI database. The data collection parameters on the Power TG host servers are also updated with the new lists and collection frequencies so that the data will begin to be sent to the PI database as soon as the tags are available.TerminologyTo understand this interface manual, you should be familiar with the terminology used in this document.BufferingBuffering refers to an interface node’s ability to store temporarily the data that interfaces collect and to forward these data to the appropriate PI Servers.N-Way BufferingIf you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering. Nway buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI Collective. (Bufserv also supports n-way buffering to multiple PI Servers however it does not guarantee identical archive records since point compressions attributes could be different between PI Servers. With this in mind, OSIsoft recommends that you run PIBufss instead.)ICUICU refers to the PI Interface Configuration Utility. The ICU is the primary application that you use to configure PI interface programs. You must install the ICU on the same computer on which an interface runs. A single copy of the ICU manages all of the interfaces on a particular computer.You can configure an interface by editing a startup command file. However, OSIsoft discourages this approach. Instead, OSIsoft strongly recommends that you use the ICU for interface management tasks.ICU ControlAn ICU Control is a plug-in to the ICU. Whereas the ICU handles functionality common to all interfaces, an ICU Control implements interface-specific behavior. Most PI interfaces have an associated ICU Control.Interface NodeAn interface node is a computer on which the PI API and/or PI SDK are installed, and PI Server programs are not installed.PI APIThe PI API is a library of functions that allow applications to communicate and exchange data with the PI Server. All PI interfaces use the PI API.PI CollectiveA PI Collective is two or more replicated PI Servers that collect data concurrently. Collectives are part of the High Availability environment. When the primary PI Server in a collective becomes unavailable, a secondary collective member node seamlessly continues to collect and provide data access to your PI clients.PIHOMEPIHOME refers to the directory that is the common location for PI 32-bit client applications. A typical PIHOME on a 32-bit operating system is C:\Program Files\PIPC. A typical PIHOME on a 64-bit operating system is C:\Program Files (x86)\PIPC.PI 32-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME. For example, files for the 32-bit Modbus Ethernet Interface are in [PIHOME]\PIPC\Interfaces\ModbusE.This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory path. For example, ICU files in [PIHOME]\ICU.PIHOME64PIHOME64 is found only on a 64-bit operating system and refers to the directory that is the common location for PI 64-bit client applications. A typical PIHOME64 is C:\Program Files\PIPC. PI 64-bit interfaces reside in a subdirectory of the Interfaces directory under PIHOME64. For example, files for a 64-bit Modbus Ethernet Interface would be found in C:\Program?Files\PIPC\Interfaces\ModbusE.This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory path. For example, ICU files in [PIHOME]\ICU.PI Message LogThe PI message log is the file to which OSIsoft interfaces based on UniInt 4.5.0.x and later write informational, debug and error messages. When a PI interface runs, it writes to the local PI message log. This message file can only be viewed using the PIGetMsg utility. See the UniInt Interface Message Logging.docx file for more information on how to access these messages.PI SDKThe PI SDK is a library of functions that allow applications to communicate and exchange data with the PI Server. Some PI interfaces, in addition to using the PI API, require the use of the PI SDK.PI Server NodeA PI Server Node is a computer on which PI Server programs are installed. The PI Server runs on the PI Server Node.PI SMTPI SMT refers to PI System Management Tools. PI SMT is the program that you use for configuring PI Servers. A single copy of PI SMT manages multiple PI Servers. PI SMT runs on either a PI Server Node or a interface node.Pipc.logThe pipc.log file is the file to which OSIsoft applications write informational and error messages. When a PI interface runs, it writes to the pipc.log file. The ICU allows easy access to the pipc.log.PointThe PI point is the basic building block for controlling data flow to and from the PI Server. For a given timestamp, a PI point holds a single value.A PI point does not necessarily correspond to a “point” on the foreign device. For example, a single “point” on the foreign device can consist of a set point, a process value, an alarm limit, and a discrete value. These four pieces of information require four separate PI points.ServiceA Service is a Windows program that runs without user interaction. A Service continues to run after you have logged off from Windows. It has the ability to start up when the computer itself starts up.The ICU allows you to configure a PI interface to run as a Service.Tag (Input Tag and Output Tag)The tag attribute of a PI point is the name of the PI point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI System documentation uses the terms “tag” and “point” interchangeably. Interfaces read values from a device and write these values to an Input Tag. Interfaces use an Output Tag to write a value to the device.Technical Support and ResourcesYou can read complete information about technical support options, and access all of the following resources at the OSIsoft Technical Support Web site: ()Before You Call or Write for HelpWhen you contact OSIsoft Technical Support, please provide:Product name, version, and/or build numbersComputer platform (CPU type, operating system, and version number)The time that the difficulty startedThe log file(s) at that timeHelp Desk and Telephone SupportYou can contact OSIsoft Technical Support 24 hours a day. Use the numbers in the table below to find the most appropriate number for your area. Dialing any of these numbers will route your call into our global support queue to be answered by engineers stationed around the world.Office LocationAccess NumberLocal Language OptionsSan Leandro, CA, USA1 510 297 5828EnglishPhiladelphia, PA, USA1 215 606 0705EnglishJohnson City, TN, USA1 423 610 3800EnglishMontreal, QC, Canada1 514 493 0663English, FrenchSao Paulo, Brazil55 11 3053 5040English, PortugueseFrankfurt, Germany49 6047 989 333English, GermanManama, Bahrain973 1758 4429English, ArabicSingapore65 6391 181186 021 2327 8686English, MandarinMandarinPerth, WA, Australia61 8 9282 9220EnglishSupport may be provided in languages other than English in certain centers (listed above) based on availability of attendants. If you select a local language option, we will make best efforts to connect you with an available Technical Support Engineer (TSE) with that language skill. If no local language TSE is available to assist you, you will be routed to the first available attendant.If all available TSEs are busy assisting other customers when you call, you will be prompted to remain on the line to wait for the next available TSE or else leave a voicemail message. If you choose to leave a message, you will not lose your place in the queue. Your voicemail will be treated as a regular phone call and will be directed to the first TSE who becomes available.If you are calling about an ongoing case, be sure to reference your case number when you call so we can connect you to the engineer currently assigned to your case. If that engineer is not available, another engineer will attempt to assist you. Search SupportFrom the OSIsoft Technical Support Web site, click Search Support.Quickly and easily search the OSIsoft Technical Support Web site’s Support Solutions, Documentation, and Support Bulletins using the advanced MS SharePoint search engine.Email-based Technical Supporttechsupport@When contacting OSIsoft Technical Support by email, it is helpful to send the following information: Description of issue: Short description of issue, symptoms, informational or error messages, history of issue Log files: See the product documentation for information on obtaining logs pertinent to the situation.Online Technical SupportFrom the OSIsoft Technical Support Web site, click Contact us > My Support > My Calls.Using OSIsoft’s Online Technical Support, you can: Enter a new call directly into OSIsoft’s database (monitored 24 hours a day) View or edit existing OSIsoft calls that you entered View any of the calls entered by your organization or site, if enabled See your licensed software and dates of your Service Reliance Program agreements Remote Access From the OSIsoft Technical Support Web site, click Contact Us > Remote Support Options.OSIsoft Support Engineers may remotely access your server in order to provide hands-on troubleshooting and assistance. See the Remote Access page for details on the various methods you can use. On-site Service From the OSIsoft Technical Support Web site, click Contact Us > On-site Field Service Visit.OSIsoft provides on-site service for a fee. Visit our On-site Field Service Visit page for more information.Knowledge CenterFrom the OSIsoft Technical Support Web site, click Knowledge Center.The Knowledge Center provides a searchable library of documentation and technical data, as well as a special collection of resources for system managers. For these options, click Knowledge Center on the Technical Support Web site.The Search feature allows you to search Support Solutions, Bulletins, Support Pages, Known Issues, Enhancements, and Documentation (including user manuals, release notes, and white papers).System Manager Resources include tools and instructions that help you manage: Archive sizing, backup scripts, daily health checks, daylight savings time configuration, PI Server security, PI System sizing and configuration, PI trusts for interface nodes, and more.UpgradesFrom the OSIsoft Technical Support Web site, click Contact Us > Obtaining Upgrades.You are eligible to download or order any available version of a product for which you have an active Service Reliance Program (SRP), formerly known as Tech Support Agreement (TSA). To verify or change your SRP status, contact your Sales Representative or Technical Support () for assistance.OSIsoft Virtual Campus (vCampus)The OSIsoft Virtual Campus (vCampus) Web site offers a community-oriented program that focuses on PI System development and integration. The Web site's annual online subscriptions provide customers with software downloads, resources that include a personal development PI System, online library, technical webinars, online training, and community-oriented features such as blogs and discussion forums. OSIsoft vCampus is intended to facilitate and encourage communication around PI programming and integration between OSIsoft partners, customers and employees. See the OSIsoft vCampus Web site, () or contact the OSIsoft vCampus team at vCampus@ for more information.Revision HistoryDateAuthorComments11-Feb-2009KMillarInitial Draft: Based on skeleton 3.0.709-Nov-2009KMillarVersion 1.0.0.0 – Initial Release11-Nov-2009MKellyVersion 1.0.0.0 Revision A - Fixed headers and footers, updated formatting, fixed all hyperlinks.21-Apr-2011KMillarVersion 1.0.0.0 Revision C - Version 1.0.0.0 of the interface is only compatible with PIAPI 1.6.1.1123-Nov-2011KMillarVersion 1.0.1.0 - Updated Vendor Software Required with “Power TG software must be version 8.3.SP1 or greater.” and updated PIAPI compatibility notes.19-Apr-2013KMillarVersion 1.0.2.0 - Update to skeleton 3.0.36 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download