by Erik Dellinger, Kepware Technologies
Before I get into Kepware’s current implementation of the BACnet Calendar and Schedule Objects (available in KEPServerEX version 5.15 and later), we should cover objects in general terms. When we talk about objects, we are essentially talking about structured data. You can think of structured data as how we store and organize data so that it can be easily and efficiently referenced and used. For example, rather than reading your first name, your last name, and then your location, you read it all at once. Structured data is a collection of properties or attributes that can contain various information, some of which is useless on its own but paints a larger and more meaningful picture when combined.
Historically, Kepware’s focus was around developing communications to collect data (such as I/O) from sensors, PLCs, and RTUs. We serve this data to an OPC client as a single point of information. Although we reference this item as a single point and and are mostly concerned with its value, we also provide other useful data as specified by the OPC Foundation (such as the item’s timestamp and quality properties, just to name a couple). Most of these properties are not used knowingly by OPC server and client users.
Beyond the inner structure of an OPC item, device or protocol-specific objects were not supported. Our BACnet/IP Driver is—or was—a great example of this. BACnet has over 50 objects defined within its specification; although Kepware’s BACnet/IP Driver supports many of these objects, we only supported select properties (items) within the object. The best way to describe this is to look at the two BACnet objects that we just implemented in our driver: Calendar and Schedule Objects.
Calendar and Schedule Objects
Before KEPServerEX version 5.15, our driver partially supported the Schedule and Calendar Objects. KEPServerEX could read some of their specific properties, such as “ObjectName,” “ObjectType,” “PresentValue,” and “ProfileName.” We also supported the “DateList” Property in the Calendar Object, which has a BACnet-specific data type called “BACnetCalendarEntry.” This property is a variable in that it can be an individual date, a range of dates, or a month/week-of-month/day-of-week reference. This data type doesn’t map directly to any OPC data type. If an OPC client and server application were to read it, they would have to request individual properties within the object. With a variable data type, there is added complexity. Our method was to import the properties as tags from the device, determine the number of BACnetCalendarEntries that the object contained, and then create an OPC String Tag for each entry.
This is probably not how BACnet objects were intended to be utilized, however. Having an OPC server parse the object for specific properties to be served to an OPC client—who in turn would need to recompile the object—is inefficient. There are also many points of possible failure, and having the engineer or Systems Integrator rebuild the object is not a great use of time. In this scenario, even if the object was rebuilt, the integrity of the data could not be guaranteed because the properties within the object were read individually and have unique timestamps.
The ideal solution is for the OPC server to read the entire object in a single read request and provide it to an OPC client as a single object—not as individual OPC items representing properties. This would ensure the data’s integrity and reduce the extra work required to deconstruct and rebuild the object.
Challenges
One issue is that OPC DA does not natively support this ability; however, it can be done with OPC UA through the implementation of Complex Data from both the OPC server and client vendors. Because OPC DA has a large install base and Complex Data support among OPC UA client and server vendors is not yet commonplace, Kepware took a different approach to ensure legacy applications have a solution. We now support the ability to read and write the entire object to and from the controller in a single request. But how do we provide this object, this complex piece of data, to an OPC DA or UA client application that does not easily support objects or complex data types?
The answer came from our development team, who decided to make the BACnet objects available to OPC client applications as a formatted compressed string. The string data type allows us to have a variable string length, which is required for the Calendar and Schedule Objects. For example, because the string data type is supported by both OPC DA and OPC UA Clients, we can map the BACnetCalendarEntry of the Calendar Object. Doing this allows OPC client applications to access the data as single piece of data without losing the data’s integrity.
One last hurdle was how we were going to present the compressed string and how it would be viewed and utilized in an OPC client. The data within the string is not easily human readable, which is a challenge in and of itself. Thankfully, OPC clients typically have a scripting tool like Visual Basic for Applications (VBA) to parse and properly present the object and its properties. We considered making the string human readable like other OPC server vendors, but after evaluating numerous OPC clients and their scripting tools, we decided to reduce the length of the string instead. Because several OPC clients’ scripting tools had string length restrictions, we felt the best approach would be to accommodate as many OPC clients as possible with a compressed format. With the detailed documentation and sample VBA code now provided with the BACnet/IP Driver, users will be able to easily and quickly parse the objects’ data and make it useful within their preferred OPC client.
With these updates, our BACnet/IP Driver enhances the monitoring and control between Building Automation Controllers and HMI/SCADA applications. With the greater flexibility, you can set the scheduling properties anywhere—even from your couch. So what do you think? Will you utilize them in your Building Automation projects?
Read more on the Kepware Technologies blog.