系统服务器系统时间与北京时间不一致解决

系统服务器系统时间与北京时间不一致解决

WinCC消息报警时间为消息触发时CPU时间（同步时钟为Slclock，即格林威治时间），报表时间为SQL数据库记录数据时间（同步时钟为服务器时间）。经查发现CPU时间与服务器时间出现时区差8时4分3秒。

为保证报警时间与报表数据一致，需修改CPU时间并将服务器时区改为与CPU同步时钟一致的格林威治时间。时间修改需对CPU下载同步后重启服务器，服务器重启完成后需对服务器时区修改为“格林威治时间”。

在对EMS系统服务器系统时间进行了更改（将系统时间显示07:34改为了当前北京时间15:34），在正常显示10S钟后系统显示时间自动减了8小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为23:35。

对系统时间设置进行检查，未发现设置出现问题。在16:13时又对系统时间进行了更改（将系统时间显示08:13改为了当前北京时间16:13），在正常显示10S钟后系统显示时间再次自动减了8小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为00:13。

将此现象电话咨询供应商（上海西门子），供应商回复将PLC与本地时间同步勾选项去掉试试。去掉PLC与本地时间同步勾选项后在在16:27时又对系统时间进行了更改（将系统时间显示08:27改为了当前北京时间16:27），在正常显示10S钟后系统显示时间还是自动减了8小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为00:27。

请示部门领导，对部门领导说明情况后在16:52再次进行了测试，在00：52出现归档数据，但时间仍然自动减了8小时。

再次联系供应商，供应商回复也不知如何解决。在商讨后决定将系统时间时区由“格林威治时区”改为“北京时区”试下。在17:05时将系统时间时区由“格林威治时区”改为“北京时区”，并将时间显示改为了当前北京时间17：07，此时时钟记时正常，查看报表数据和曲线数据出现每分钟正常数据归档，其归档时间与系统显示时间一致。由于在00：52出现归档数据，因此在此时间之前系统无法保存归档数据。当切换另一报表后其当前正常显示的归档数据无记录。最终所有归档数据在00:53全部恢复正常。

将此现象电话咨询供应商（上海西门子），供应商回复已无法通过电话联系方式找到出现此问题原因。若要进一步查找原因需到现场进行软件停机、PLC下载、断网等一系列操作将会导致过程中MTTP系统无法正常工作。

以系统5#温度检测点为例：

经确认，在系统更改为“北京时区”前所有数据时钟采用“格林威治时区”其归档数据在存在8小时数据丢失。曲线数据采集的时间为服务器系统时间，标尺时间也是读取的服务器系统时间但是连续的。因系统显示时间自动减了8小时从而导致了8小时数据丢失。因进行了人白灌装，其打印的PMS报表数据正常。MTTP系统数据归档时间与PMS报表显示时间同是读取的EMS系统服务器系统时间。因此，可确认EMS系统服务器系统时间自动减了8小时。在系统更改为“北京时区”后所有数据时钟采用“北京时区”其归档数据正常。

工程师对EMS系统服务器系统时间与北京时间不一致问题到公司现场进行了检查。通过对系统相关设置检查后，其设置均正常。

为保证其系统各类时间一致，西门子工程师提出了解决方案：将与CPU通讯的CP343-1卡件版本号由V2.0升级为V2.2以保证CPU时间与本地时间时时同步（CP343-1卡件版本升级对系统无影响）。由于现使用的STEP7为V5.4，要将CP343-1卡件版本号由V2.0升级为V2.2。STEP7版本需为V5.5。EMS系统现处于运行过程中无法对ＳＴＥＰ7版本进行升级。现将CPU与供应商工程师安全的操作终端连接进行CP343-1卡件版本号升级（由于升级后的CP343-1卡件版本号是下载到CPU中的，因此在系统上看到的CP343-1卡件版本还是V2.0）。对STEP7版本升级为V5.5后系统时间正常。

本文来源：https://www.2haoxitong.net/k/doc/fe20cb2191c69ec3d5bbfd0a79563c1ec5dad790.html