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 Change of Value (COV) – Read more…
Limitations of COV system in General – Read more…
Specific Limitations of BACnet COV – Read more…
IN THIS ISSUE
Unsafe electrical practices:
FieldServer Gateway (Dual Serial)
FieldServer’s Web Server
In a nutshell:
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.
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.
These are some of the examples you can produce with this system, the system is only limited by your imagination.
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.
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.
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.
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’.
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
Data Client sends messages to the device to subscribe to COV notifications.
COV Server device monitors the property values of subscribed objects and the COV change criteria.
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.
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.
Establishes a relationship between a COV Server and a COV Client.
Subscriptions have the following attributes :
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:
Subscribe to a property :
Either of these cases trigger notification:
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.
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.
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.
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.
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.
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.
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.
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.
2008 Chipkin Automation Systems – email@example.com
BACnet is a registered trademark of ASHRAE.