EMS 主 站 对 厂
站设备的大多数采集命令，都有一旦执行不可中断的性质。以全数据请求
(简称：
总召
)为例，对一个具有几千个数据点的 RTU 的全部数据采集一遍，往往需要
几十帧报文，花费几十秒钟时间，具体视信道带宽的不同而有不同。
在全数据采集过程中，当
RTU 某个刚刚被采集过的数据内存的数据发生变
化时，这种变化不能立即被送往主站，必须等到本轮全数据请求全部完成后，
在接下来的变化数据请求中被送往主站。
如果这个站的全数据采集需时
40 秒，在它刚刚采集到 10 秒钟的时候，刚
才
10 秒内已被采集过的某个数据内存的数据发生变化，那么这个变化了的数
据，起码要在
30 秒钟以后，才能被送往主站。
我们当然可以在规约的编程上来改变这个总召不可中断的局面，比如，在
10 秒时中断总召命令，先传送上面所说这个刚变化了的数据，这是能够做到的 。
但请注意，我们为什么要发全数据请求命令
?因为在经过了很长一段时间的变化
数据请求以后，主站数据库中这一块数据是否还与厂站保持一致
?我们是有疑问
的，很多数据在
12 个小时内都没有被刷新一次，在他们被主站的各种应用程
序几十次地读取、比对、处理中，会不会出错
?为了保险，这个时候，妥当的做法
是把这个站的数据全部刷新一遍，以确信，这时候主站数据与厂站实际状态是
一致的，如果不这样做，很可能更多的面上的错误会发生在这个厂站的数据中。
所以，每隔一段时间对一个站的整个数据刷新一遍，也是很重要的，不可偏废。
再说，在调度可以接受的限度内，这个变化了的数据稍微延后一点送上去，又
有何妨
?比较利弊得失，还是不中断的好。
现在再来探讨这个延迟上送的变化了的数据带来的问题。
如果这个数据变化不大，虽然已经越过了死区，必得上送，也只是平稳负
荷曲线上的一个小小的波动，虽然延迟了
30 秒才到达主站的数据库，但在当
找电力资料，就到一览电力文库