We recently upgraded CS3000 to Centum VP. Yokogawa DCS. Processor CP471.

After the commissioning was done, things went smoothly for a few months. Later some DPR data started drifting off and DPRs were not getting generated at correct times.

After investigation it was found that the CPU time is off by 13.5 hours (probably) set to some other country’s time.

Now what is strange was that in Yokogawa Centum VP System, the CPU clock cannot be corrected online.

OEM says that to correct the CPU time, would require an offline download of some file. This is impractical from our standpoint as process cannot be shutdown.

So the DPR was subsequently corrected thru lots of complicated programming steps, to offset for the time mismatch between HIS/HMI time and CP471 (CPU) time.

It all worked out well only to realize a year later that the time offset, applied in programming for DPR, had to be changed as the CPU clock had drifted again and needed an offset correction.

While it all works well, the question is why should CPU clock correction in Yokogawa DCS (FCS) require offline download? CPU clocks can drift like we often see in standalone desktop computers also. The clock drifts steadily by a few mins over a long period of time. So if offline download is the only way to correct CPU Clock drift / time, in Yokogawa DCS, doesn’t it make the system impractical for use?

I am sure I am badly under-informed cos Yokogawa DCS’ are quite reliable robust and wide spread. So I am definitely missing out on something on the issue. Request experts on Yokogawa systems to kindly help with some info on the issue of CPU time corrections in Yokogawa FCS.

Is it true that CPU time correction requires offline download only?

How does CPU clock drifts gets handled then, if they occur over a period of time? Would it always require a process shutdown to correct the CPU Time?

Thanks in adv & regards

 

Well do you have any ENG server or SNTP server in the network? In principle the V-net-IP time sync function will be initiated by any Time master Devices(HISs/ENGSs or any simialr devices) in the n/w which starts up last. or using a SNTP Server in the n/w which ensures time sync among all the devices connected in n/w. In reality the FCS CP card cahnges will not be the cause where as trailing clocks of any of the other HISs/ENGs shall be the probable reasons. Btw pl. let me know your n/w archirtecture with connected devices..

 

If it was all correct at commissioning then it was possibly set up correctly. Some windows10 updates can undo a local policy which directs HIS to a NTP (server or GPS clock) and sets the HIS to look at its own time or an internet time source that may not be accessible.