|
|
The deluge of changes problem
These event reporting systems are commonly implemented to reduce the bandwidth requirements for monitoring remote devices or to ensure that the data client sees changes whose durations are less than their minimum polling interval. When a client reduces the frequency of its polls for data or reduces which objects it polls this reduces the bandwith requirements of the system. To compensate for the lower frequency of updates a COV system may be employed.
If COV systems are employed to 'guarantee the delivery of criticial data' great care should be taken is assessing the so called 'guarantee'. The guarantee is often based on the assumption that changes are infrequent and small in scope but this isn't always the case. Often a single change can spawn a number of changes and those changes can spawn more changes in a system similar to a nuclear reaction. The more changes that occur the more notifications that must be sent. If all the changes occur in a short interval then it easy to foresee a situation where a network or data client can be deluged with notifications. Now we have to assume there is enough bandwidth to handle sending them all and that each client can handle all the incoming messages quickly. If the notifications require confirmation then the speed of the client in processing the messages is material. If there is no notification required then it is conceivable in a poor BACnet implementation that the client could drop messages when its buffer is full.
It is very difficult to test these conditions because the test requires monitoring large data sets and the test setup requi