July 2008 Newsletter

FieldServer’s Web Server

Did you know that a FieldServer can be used to serve web pages ? Did you know that the web pages can be animated with real time data collected by the protocol drivers talking to real field devices ? Were you aware that we can serve sophisticated pages like this one, animated with data from a Canatal Air Conditioner ?

This month we are featuring the FieldServer WebServer. Please explore the capabilities of the WebServer by reading our newsletter.


BACnet School

BACnet Change of Value (COV) – Read more…

Limitations of COV system in General – Read more…

Specific Limitations of BACnet COV – Read more…

IN THIS ISSUE

» FieldServer Gateway (Dual Serial) «
» FieldServer’s Web Server «
» BACnet Change of Value (COV) «
» Limitations of COV system in General «
» Specific Limitations of BACnet COV «

Please rate our newsletter:Good
Decent
Bad
Needs Improvement
Submit

Unsafe electrical practices:


Click for larger version



FieldServer Gateway (Dual Serial)

Dual Serial – Ethernet
FS-B2510
The FS-B2510 Dual Serial-Ethernet gateway provides a wealth of features to enable data transfer between different devices and networks utilizing serial and Ethernet protocols. The extensive library of FieldServer drivers provides easy interoperability with devices and networks used in building automation, HVAC, fire and process control industries. The FS-B2510 is particular cost effective in the integration of two devices/systems utilizing serial protocols such as a fire alarm control panel to BACnet MSTP.
The FS-B2510 is one of the FS-X30 Series FieldServers designed to meet the needs of system integrators in designing a complete interoperable system. The FS-B25 Series brings together the powerful FieldServer driver library with state-of-the-art gateway design. This FieldServer includes twi serial connections (RS-232 or RS-485, software selectable) and one 10/100BaseT Ethernet ports. The multiport design allows for serial-to-serial interfaces or interface from mulitple serial products to an Ethernet or LonWorks network. The Ethernet port enables the integrator to connect a PC to download configuration changes without disturbing the system connections and without the additional cost of an external hub.CAS sell, support, install, configure and develop custom drivers for FieldServers. With every FieldServer purchased from CAS that includes a BACnet protocol we provide a free license to the CAS BACnet Explorer which can be used to test / prove the BACnet interface is working.

 


FieldServer’s Web Server

In a nutshell:

  • The FieldServer reads data from field devices.
  • This data can be used to animate web pages that can be served by the FieldServer.
  • Using a browser, a customer or user can monitor data from field devices and also control them.


A little more detail:

The FieldServer Web Server allows you to display and change data in a FieldServer. The FieldServer’s data is obtained by communication with remote devices such as gas Detectors, Lighting Controllers and many more.

The web server is a front end HMI (human machine interface) that can serve screens and data to any web browser such as Internet Explorer. Amongst other things, it allows your users to view and change values on your devices with out having to install any special software or be anywhere near the site.

Since the system is built in to a webpage, most of your users should already have the required skills to operate the system (click the link, push a button, flip a switch), a lower learning curve and less training. So simple that just about anyone can operate the system.

Your users can connect and change values on your devices from anywhere that has an internet connection and a web browser. Imagine sitting down in the comfort of your own home, and browsing to your site, viewing the status and making any changes that are needed, then rolling over and going back to sleep, with having to set one foot on the site.

The values on your device can be displayed in a number of ways from simple text and progress bars to animated images and sliders, its up to you how you want to display your data and the system is flexible to do just about anything you can think of, while remaining simple enough for anyone to use.

The system uses a simple template tag system to display and change the data on your devices; these tags can be inserted in to any html document and placed on the FieldServer. The server will then will run thou and strip out these tags and replace them with the data from your device. Its much simpler then it sounds, put this tag where you want to show your data. The template tags are built with web designers in mind, there simple to use and simple to debug.
How it all works:

This system works by creating a mini web server on our FieldServer that the users can browse to. When a user browses a webpage, the FieldServer searched the html document for special template tags, if the FieldServer finds these special template tags in the html document, it replaces them with data from your device. When you push a button on one of these web pages, the value is sent from your webpage to the FieldServer, to your device.

 

 

Step 1: FieldServer is configured to read data from field devices using RS232/ RS485/ Ethernet, Controlnet, DeviceNet, DH+, Modbus+ and any combination of drivers from the extensive protocol library. Over 100 protocols are available.

Step 2: A browser surfs the FieldServer. Pages served are just like any other html pages except that they can include animations based on the real time data obtained from the field devices. The pages can also contain elements to change the data in the FieldServer. These changes then get sent back down to the field devices, if this is what you require.

Step 3: Data read from the field devices can also be served to other field devices using another protocol. It depends on your requirements.

Examples

These are some of the examples you can produce with this system, the system is only limited by your imagination.

Simple Example

In this simple example we are only using the very basics of the template system, (display text and action buttons) but you can instantly see the power of this system, its easy to read, it’s easy to operate, it provides all the information that the user needs about the building.


Sleek and Pretty Example

In this example we put an information tag on an image of the factory; the loading doc has two tags associated with it, Lights and AC. You can see that the lights are on and the AC is off, the boarder is flashing red indicating a panic, the user then could click on this tag and get a screen similar to the one above where they can get more information and acknowledge the alarm.


Mirror example

In this example we copied the front display of the real device, anyone that has used the device before can quickly and easily navigate this interface.


BACnet School


BACNET CHANGE OF VALUE (COV)

1.0 – Introduction

Most field devices are passive servers. They wait passively for a system to poll them for data and only then do the devices respond. A consequence of this is that the data client only knows the value of an object property when it polls for the value. If the duration of an event (change of value) is shorter than the interval between polls then the data client will not know the event occurred.

 

BACnet provides a solution for this by defining services to report events. These services allow a device to be transformed from a passive server to an active server since it is now capable of sending messages reporting the value of an object property based on some event rules. BACnet COV is a sub-set of the ‘Alarm and Event Services’.
This article discusses how the technology operates and then provides a discussion on some weaknesses in the COV system.

2.0 – A simplified definition of BACnet COV

Data clients subscribe to an object for COV reporting. The device monitors the value of the object property, monitors the subscription list and the change criteria. When the change criteria are met the devices sends notifications of the new value to the subscribers.

3.0 – Not all devices / objects support COV

The BACnet COV system is not a mandatory part of the protocol. Each vendor decides if they want to support it. In addition, each vendor gets to decide which properties of which objects support COV.

The device object of a COV server indicates whether there is support for COV. Beyond that you have to look for the presence of certain properties such a “COV Increment’ to tell if an object supports COV or you have to refer to the vendor documentation.

4.0 – How COV Works

Subscribe

Data Client sends messages to the device to subscribe to COV notifications.


The server must accept the subscription.

Monitor

COV Server device monitors the property values of subscribed objects and the COV change criteria.

Notify

When a change has occurred that meets the COV change criteria the server sends notifications to the subscribers or for those objects with a COV Period defined, notifications are sent based on the period if there has been no change.

Process Notification

The data client must process the notification and update the display, log, etc.

Unsubscribe / Renew Subscription

If the data client no longer needs the subscription it unsubscribe. If it needs the subscription maintained then the client should periodically re-subscribe.

The system is a little more complex than this. For example, subscriptions have durations and there is more than one way the notification can be sent.

5.0 – Key Elements of the COV Technology

COV Server :

A BACnet device that supports COV, accepts subscriptions and sends COV notifications messages to a COV Client.

COV Client :

A BACnet device, typically a SCADA or Logging application, which can subscribe for COV notification and which can process the notification messages.

Subscription :

Establishes a relationship between a COV Server and a COV Client.

Subscriptions have the following attributes :

  • Subscription to an Object or to a Property BACnet provides two services for subscription. One subscribes to an object and the other to a property of an object.
  • Identification of the Subscriber The server needs to know where to send the notifications.
  • Object Identifier Eg. Analog Input 1 If subscribing to a property then the property must be identified too.
  • Lifetime Is indefinite or a specific number of seconds. Values can be large.
  • Notification Type Notification can be sent with/without requiring confirmation from the data client.
  • COV Increment This parameter is only used in subscriptions to object properties. If not specified in the subscription the object uses its own increment.
Notification :

A message which reports the current value of the changed property as well as the current state of the objects Status Flag property if it exists. The notification also contains the number of seconds remaining to the subscription. Confirmed notifications require a response from the COV client.

6.0 – Change Criteria

The change criteria are based on the type of subscription

Subscribe to the object :

Either of these cases trigger notification:
1) If the status flags change at all
2)If the Present Value changes:

  • Binary, Life Safty and Multistate Objects : any change to Present Value
  • Analog, Loop and Pulse Objects: change by COV_Increment
Subscribe to a property :

Either of these cases trigger notification:
1) If the status flags change at all (if the object has status flags)
2)If the Property Value changes:

  • Property is of type REAL : change by COV_Increment ( which may be defined in the subscription or may be the native increment defined in the device).
  • Property is of some other type: any change to Present Value


7.0 – Discussion and Limitations of COV

7.1 General Discussion

There are some intrinsic problems with event or change reporting systems.

In our experience it is fairly common to learn that a well configured system failed to deliver the critical information only after a significant failure. We learn the hard way that we polled for data too slowly, the logger was offline when the notification was sent or that the logger was swamped with data because of the failure of incoming feed. With this in mind we draw your attention to some if the issues you should consider.

7.1.1 – 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 requires a knowledge of how changes can spawn other changes within a device and / or a system. A consequence of these difficulties is that the performance of COV systems can be unpredictable.

7.1.2 – The offline Subscriber problem

A subscriber may be offline when a notification is sent. If the subscription required confirmed notification then this could present a temporary but significant loss of bandwidth while the COS server waits the timeout period before sending the next notification. If no confirmation was required then there is no way of knowing that the subscriber was offline and even if it wanted to the COS server device cannot signal this in anyway.

The COV system does not require vendors to manage notifications sent to offline subscribers. Thus the COV server does not have to queue them and resend them. Thus, it is possible for a COV client to lose its data synchronization with the Server. The only way around this is to use occasional polling. However, if the data client was a logging system then the damage is already done and the log records will not be made.

7.2 – Specific Limitations of BACnet COV

7.2.1 – Subscriptions may be lost on reset

The BACnet spec does not require vendors to maintain the subscriptions if the device resets. Thus a reset may result in the loss of all subscriptions. Now the system is dependent on the frequency of the re-subscription by the data client. That frequency is a vendor choice too and some systems don’t send periodic re-subscriptions.

7.2.2 – Single/Multiple Subscriptions

A single data client can potentially subscribe more than once to the same data object. This is possible because in identifying itself, in the subscription, the client provides two elements of information – identifier and handle. The identifier tells the server where to send responses. The handle is a number allocated by the client for some internal purpose. Changing the handle is enough to make a subscription unique and hence it is possible to have multiple subscriptions to the same object from the same client.

7.2.3 – Subscribing to Arrays

The spec allows vendors to choose whether to support subscriptions to all or particular elements of the array.

7.2.4 – Variable Number of Subscriptions

Each vendor chooses how many subscriptions to an object / property are supported. The spec requires that at least one must be supported. You should assume the list is finite and fairly short.

Its conceivable that subscription space could be wasted by temporary subscriptions from test equipment of software thus denying room for important subscriptions.

It is important to understand how your COV client application handles and reports failed subscriptions as these events can be as important as the event they are attempting to monitor.

7.2.5 – Unconfirmed Notifications can be sent without Subscription

The spec allows a device to send unconfirmed notifications for any property of any object to any other device on the network. Thus a device can send changes of a object property that has a wide area interest such as an outside air temperature. The vendor chooses if they wish to implement this, which objects, which properties and the frequency of the notification.

7.2.6 – Notifications can be sent without a change of value

The criteria for triggering notification messages requires notifications to be sent if the Status Flags associated with the object change even if the value hasn’t changed. This is potentially, important information but a number of data client systems ignore this element of the notification data.
Read Bacnet Change of Value (COV) article.


2008 Chipkin Automation Systems – bacnet@chipkin.com
BACnet is a registered trademark of ASHRAE.

If you liked this post;
  • Please consider subscribing to our RSS feed