另外要知道的就是WinCC的变量扫描机制。
WinCC有一个关键的机制叫数据管理器，在这个问题里，咱们可以把它看成外部变量的映像区。根据某些条件，映像区的数据会根据外部变量值的变化而变化。各个使用外部变量值的模块必须通过这个映像区来读写外部数据。数据管理器并不会激活说有项目变量，只有正在被使用的变量是“激活的”。
在WinCC启动时，数据管理器的数据变化是这样的：
1、模块向提出数据要求
2、数据管理器激活这些变量
3、数据管理器从PLC取得这些变量并刷新映像区
4、模块读取映像区时得到更新的数据
实际情况会更复杂些，但是这个基本顺序决定了上面出现的情况。

现在再来看WinCC重启前后发生了什么。
>WinCC重启前，映像区里这个变量值由0变1
>第一条报警“来”记录生成
>WinCC重启，建立映像区，此时映像区里的值为默认值0。这个过程是由无到有，而不是由1变0，没有下降沿，没有生成报警“走”
>报警系统要求取得报警变量值
>映像区刷新，值变为1
>第二条报警“来”记录生成
上面的描述已经可以看出在WinCC现有机制下，这个现象的必然性。那么这种设计是否合理呢？
这个问题涉及了“外部变量值在系统重启时是否应该保持”的问题。这个机制在不同情况下会有不同的需求，在这里就不分析了。总之，西门子认为不保持更大众化。
那么报警遵从变量刷新机制导致了“比实际情况多了一条报警”是不是合理呢？这里还有另一个矛盾，如果PLC在WinCC重启过程中如果有又有->“走”->“来”这个过程怎么办呢？
WinCC在自己的“WinCC报警扫描”机制里采用了“如实反映”的态度，看到什么就报什么，没看见就不报。
如果实际需求中，这些报警在WinCC里的记录真的不能有丝毫差错，那么在项目实施过程中有两个办法：
1、不重新启动WinCC
2、采用PLC扫描的报警机制

结论：
WinCC是一个通用的自控软件，面对特定状况的一些合理需求时处理起来会有些麻烦。
各种自控产品的设计和实际项目需求之间都有这么一个距离，通用的产品面对具体需求时距离大些，但是适用范围更广；专用产品与需求距离小，但是适用范围也小。
这个距离就是工控行业工程师的生存空间。