《系统服务器系统时间与北京时间不一致解决》由会员分享，可在线阅读，更多相关《系统服务器系统时间与北京时间不一致解决（2页珍藏版）》请在金锄头文库上搜索。
1、系统服务器系统时间与北京时间不一致解决WinCC 消息报警时间为消息触发时 CPU 时间（同步时钟为 Slclock，即格林威治时间） ，报表时间为 SQL 数据库记录数据时间（同步时钟为服务器时间） 。经查发现 CPU 时间与服务器时间出现时区差 8 时 4 分 3 秒。为保证报警时间与报表数据一致，需修改 CPU 时间并将服务器时区改为与CPU 同步时钟一致的格林威治时间。时间修改需对 CPU 下载同步后重启服务器，服务器重启完成后需对服务器时区修改为“格林威治时间” 。在对 EMS 系统服务器系统时间进行了更改（将系统时间显示 07:34 改为了当前北京时间 15:34） ，在正常显示
2、10S 钟后系统显示时间自动减了 8 小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为 23:35。对系统时间设置进行检查，未发现设置出现问题。在 16:13 时又对系统时间进行了更改（将系统时间显示 08:13 改为了当前北京时间 16:13） ，在正常显示 10S 钟后系统显示时间再次自动减了 8 小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为 00:13。将此现象电话咨询供应商（上海西门子） ，供应商回复将 PLC 与本地时间同步勾选项去掉试试。去掉 PLC 与本地时间同步勾选项后在在 16:27 时又对系统时间进行了更改（将系统时间显示 08:27 改为了当前北京
3、时间 16:27） ，在正常显示 10S 钟后系统显示时间还是自动减了 8 小时，此时查看报表数据和曲线数据发现有数据归档，归档时间为 00:27。请示部门领导，对部门领导说明情况后在 16:52 再次进行了测试，在00：52 出现归档数据，但时间仍然自动减了 8 小时。再次联系供应商，供应商回复也不知如何解决。在商讨后决定将系统时间时区由“格林威治时区”改为“北京时区”试下。在 17:05 时将系统时间时区由“格林威治时区”改为“北京时区” ，并将时间显示改为了当前北京时间17：07，此时时钟记时正常，查看报表数据和曲线数据出现每分钟正常数据归档，其归档时间与系统显示时间一致。由于在 00：
4、52 出现归档数据，因此在此时间之前系统无法保存归档数据。当切换另一报表后其当前正常显示的归档数据无记录。最终所有归档数据在 00:53 全部恢复正常。将此现象电话咨询供应商（上海西门子） ，供应商回复已无法通过电话联系方式找到出现此问题原因。若要进一步查找原因需到现场进行软件停机、PLC下载、断网等一系列操作将会导致过程中 MTTP 系统无法正常工作。以系统 5#温度检测点为例：经确认，在系统更改为“北京时区”前所有数据时钟采用“格林威治时区”其归档数据在存在 8 小时数据丢失。曲线数据采集的时间为服务器系统时间，标尺时间也是读取的服务器系统时间但是连续的。因系统显示时间自动减了 8小时从而
5、导致了 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 后系统时间正常。
