Andover Continuum 1.73

BACnet clients must respect the servers report of supported services

In BACnet when a client connects to a server it has the responsibility of enquiring what services the server supports and then only using the supported services. In BACnet a server should be driven to a failed state if it receives a message requesing a service that isnt supported.

There are always grey areas in specs. Despite the plugfests, despite the testing … there will always be little gotcha’s. Isnt that why there are plugfests in the 1st place.

We recently supported a site where the server device reported that it did not support COV. Despite this ,the Andover Continuum software sent COV subscription requests. This caused a failure on the server device which was not able to handle them correctly.Normally the Andover Continuum respects the service capability of the server device but in this case additional programming had been configured in a program block which used subscriptions. These program blocks appear in this configuration not to have checked the supported services list before using one. Normally the server device responds to requests for unsuported services correctly – with an rejection message.

The problem was hard to diagnose for the following reasons;1. The problem manifested itself by allowing one server device to be recognized and its points were seen but when an identical (except for device instance id) was added then both servers failed.2. An attempt was made to emulate the problem offsite. The same controller and software version were used. The offsite test did not use the same configuration. Offsite , we were able to bring in the service devices and see the points. However, there were no program blocks and thus the problem did not show up.3. We obtained communication logs from site. The logs did show problems but these were a manifestation of the failure in the service devices caused by the COV subscription. Thus these errors were red herrings.4. The subscription message is sent early after the system is reset. Thus the subscription message was not captured in the logs.

 

Conclusions;

  1. It is probable that this same problem exists in all versions since 1.73 since we have not seen a correction notice.
  2. There is no substitute for capturing full logs from a site. Logs should be captured using external devices to avoid placing any additional load on the devices already installed on the network.Using an external device can be as simple as using a USB-485 converter. Chipkin Automation System has software tools for capturing BACNet MSTP logs. They are available free of charge. Call or email us for a free copy.

© Chipkin Automation Systems 2007