Pi interface for Siemens Spectrum Power tg (Linux)
Sample PISIPowerTG.sh File
Download 0.55 Mb.
|
- Navigate this page:
- Interface Specific Failover
Sample PISIPowerTG.sh FileThe following is an example startup script file. The file is based on the PISIPowerTG.sh_new file included in the installation kit. The only section of the script that should be edited is the site-specific command-line parameters near the end of the file. #!/bin/sh # "@(#)PISIPowerTG.sh 1.0.2.11 (24-Apr-2013)" # # PI Interface for Siemens Spectrum Power TG # # Shell script to start 'PISIPowerTG' as a background process # # (C)Copyright OSIsoft, LLC. San Leandro, California 2009-2013 # # Revision # 1.0.0.0 09-Nov-2009 KJM > Initial Release # 1.0.2.0 24-Apr-2013 KJM > Reorder command-line arguments # INTF_NAME=PISIPowerTG SCRIPT=$0 #
# log_message() { echo "$1" if [ -x $PIHOME/bin/shootq ]; then $PIHOME/bin/shootq "${SCRIPT} > $1" fi } #
# if [ ${PIHOME:-notdefined} = "notdefined" ]; then echo "ERROR > The PIHOME environment variable has not been defined" exit 1 fi #
# ISRUNNING=`ps -ef | grep "${INTF_NAME} " | grep -v grep | grep -v {SCRIPT} | grep -v go_pistart` if [ -n "$ISRUNNING" ]; then log_message "ERROR > Interface (${INTF_NAME} process) already running" exit 1 fi #
# WORKDIR=$PIHOME/dat echo "Output file is \"$WORKDIR/${INTF_NAME}.out\"" # if output file exists then rename as .old file # if [ -f $WORKDIR/${INTF_NAME}.out ]; then echo "Renamed existing \"${INTF_NAME}.out\" as "${INTF_NAME}.old\"" /bin/mv "$WORKDIR/${INTF_NAME}.out" "$WORKDIR/${INTF_NAME}.old" fi #
# log_message "Starting interface \"${INTF_NAME}\"" #================= Interface Specific Parameters ================= # # Required Parameters # -host=XXXXXX[:portid] PI server hostname and port id. # -ps=#### Point source. # -id=# Interface identifier. # -data=#### Name of the Input Data File. # -alarm=#### Name of the Input Alarm File. # -qualcodefile=#### Name of the quality code definition file. # -uht_id=# UniInt Health Tag ID. # # Optional Parameters # -renamedata=#### Rename Input Data File after processing. # -renamealarm=#### Rename Input Alarm File after processing. # -onlyconnected Only process files when connected to PI server. # -debug=#### Interface specific debug options. # #--- Edit the following line --- ./${INTF_NAME} -host=XXXXXXX:5450 -ps=TG -id=1 \ -alarm=/lg/scada/dat/his/msgdata.his.1.PI.dat \ -data=/lg/scada/dat/his/measdata.his.1.PI.dat \ -qualcodefile=/lg/scada/fg/en_US/data_qualities.ini \ > ${WORKDIR}/${INTF_NAME}.out 2>&1 & exit 0
IntroductionThe 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. Directory: interfaces interfaces -> Interface to the pi system Version 37 and Greater interfaces -> Citect Interface interfaces -> Interface to the pi system interfaces -> How to Contact Us interfaces -> How to Contact Us interfaces -> Emerson Deltav batch Interface Download 0.55 Mb. Share with your friends:
|