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

系统服务器系统时间与北京时间不一致解决 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系统现处于运行过程中无法对STEP7版本进行升级。现将CPU与供应商工程师安全的操作终端连接进行CP343-1卡件版本号升级(由于升级后的CP343-1卡件版本号是下载到CPU中的,因此在系统上看到的CP343-1卡件版本还是V2.0)。对STEP7版本升级为V5.5后系统时间正常。