Re: [foxboro] Time Synchro

Dave,

Here is the short "long" answer:

The one thing that TCPtimesync does not do (and this is by design) is the
automatic DST change of the IA.

So, TCPtimesync will keep your IA node synced with the time reference
throughout the year except the DST change. In regards to the DST change
there are several options on how you can use the package:
 
 1. You have a time reference that changes automatically to DST and your IA
is changed manually to DST time. Your IA system stays synced to minutes and
seconds all the time.

 2. You have a time reference that does not change DST (it follows UTC, for
example) and your IA is changed to DST time. Your IA system stays synced to
minutes and seconds all the time.

 3. You have a time reference that changes automatically to DST and your IA
is not changed to DST. Your IA system stays synced to minutes and seconds
all the time.

 4. You have a time reference that changes automatically and you do not want
to change manually the IA and you can accept a smooth time adjustments over
a longer period (about a day).  Your IA system stays synced to minutes and
seconds all the time except the period of smooth transition after the
automatic DST change of the reference.
 




Why does the IATimesync program doesn't adjust the time at once?


There are mainly 3 major reasons:

1. The Historian can lock when setting the time back abruptly. By the way,
this is one of the reasons why IATimesync adjusts the MTK smoothly one
second at a time. Also when stopping the historian, changing the MTK back
one hour and restarting the historian will produce confusion on the trends
for the next hour since the samples after the time change will be interlaced
with the samples before the time change. Some customers accept this, other
customers don't so they may even keep the historian stopped for an hour.


2. The FoxView WILL LOCK when setting the time back abruptly. Because of
that, the OFFICIAL Foxboro procedure for the DST adjustment in spring (when
we set the time back) talks about REBOOTING THE OPERATOR WORKSTATIONS ONE BY
ONE. When exploring automatic DST adjustment within the IATimesync It was
established that AUTOMATIC WORKSTATION REBOOT IS UNACCEPTABLE (imagine you
are in the middle of a plant upset, operators are hastily jumping from one
process screen to the other and then the workstations first freeze and then
start rebooting one by one !!!), and this is one of the reasons why the
automatic DST adjustment feature was not implemented.

3. PROCESS SPECIFICS. Considering the flexibility of the Foxboro DCS system
there are plenty of customers that implement time sensitive process logic
within CALC or IND blocks. The logic of this blocks can easily trigger
process actions based on time or time intervals, so setting the time back
and forth by one hour can have dramatic consequences on the process if the
block logic did not take into account the automatic DST adjustment. 



In conclusion, even if the reasons #1 and #3 might be addressed with system
and process engineering, the automatic DST adjustment is presently not
implemented mainly because of the reason #2, the required reboot of the
workstations.



Sylvain.

Sylvain Nadeau
Systems Integration  & IT
Invensys Process Systems 
INVENSYS SYSTEMS CANADA INC.
snadeau@xxxxxxxxxx
514-421-8107
Fax:514-421-8054




-----Original Message-----
From: Williams, Dave G SUKOP-CME/72/04
[mailto:dave.g.williams@xxxxxxxxx]
Sent: April 30, 2003 3:51 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Time Synchro



Sylvain,

How does Foxview respond to these automatic time changes?


Dave Williams
Snr Power and Control Engineer
Shell UK Oil Products Limited
Stanlow Manufacturing Complex, PO Box 3, Ellesmere Port, South Wirral =
CH65 4HB, United Kingdom

Tel: +44(0)151350 4480 Fax: 4566 Other Tel: +44 (0)7799 657836
Email: dave.g.williams@xxxxxxxxx
Internet: http://www.shell.co.uk

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: