September 2011
Article
AutomatedBuildings.com

True Analytics™ - Energy Savings, Comfort, and Operational Efficiency
Ecorithm - Cloud-Based Analytics Software

(Click Message to Learn More)


Open access to vendor control languages
Or more control, less vendors.
 
Nino Kurtalj
Nino Kurtalj, President,
Elma Kurtalj Ltd

Contributing Editor



Articles
Interviews
Releases
New Products
Reviews
Cube
Editorial
Events
Sponsors
Site Search
Newsletters
Belimo
Archives
Past Issues
Home
Editors
eDucation
Distech Controls
Training
Links
Software
Subscribe
Reliable Controls

For years every vendor has had his own way of programming the base processes of BMS. Every vendor claims that their way of programming for these processes is the most understandable.

To understand the programming needs for BMS infrastructure, we need to understand the typical modern topology of BMS infrastructure. As we know, everything today has to be networkable. For the last twenty years we have talked about open systems, about interoperability, in plain English, we talked about a common understandable language between humans and machines. Still, we have not really achieved that particular goal.  Where are the problems? Why are we still asking commissioning engineers about their experiences with a particular vendor's equipment? Do we ask ICT engineers what their experience is with Lenova or HP PS? Clearly, our industry is still very proprietary. The truth is that we have widely deployed LonWorks as well as BACnet devices. LonWorks has a good commissioning tool at the M2M level but a very poor interface for common ICT services. BACnet on the other hand, has no existing independent BACnet commissioning tool. If one exists, please send me the information, as I got the impression that there is no intention to build one. Anyhow, as we see the general idea is still to keep it close. We do talk about open protocols, but we do not open our networks to other participants.

Let's start from the very beginning and answer the question - what components make a BMS network? In reality, all three of the most-used infrastructures look more or less the same. For example, Modbus. We can connect to 32 Modbus RTU units over RS485, and then we jump to TCP, so the infrastructure will talk over Modbus TCP generally. All today's HMI systems have a “driver” for Modbus TCP. Further developments in PC level programming; at the RTU level, we could have two types of controllers, programmable and preprogrammed. What is the difference? Preprogrammed controllers have register specification, and we can get the current values by asking what is at the requested register. Simple and very efficient. Where do we find such controllers?  For example; most chiller manufacturers will have a card with such capability, or UPS manufacturers, generally any serious BMS equipment manufacturer will have such an approach. With the programmable controllers, the situation is a little different. There are very few manufacturers who support an open programming environment like the IEC 61131-3 standard.

IEC 61131-3 is the international standard for programmable controller programming languages. It specifies the syntax, semantics and display for a suite of PLC programming languages:

•    Ladder diagram (LD)
•    Sequential Function Charts (SFC)
•    Function Block Diagram (FBD)
•    Structured Text (ST)
•    Instruction List (IL)

IEC 61131-3, specifies five standard programming languages, and there are no variations or dialects. That is the most important point! Once you have learned them, you can use them on a wide variety of controllers based on this standard. Simply, transition from one vendor to another is a very simple process. I will not go deeply into the standard, but it is at this moment the best possibility at the controller level. Therefore, everyone  who is responsible for the creation of tendering documentation should include that particular request as part of must have requirements.

After the pre-programmable and free programmable world of controllers we are at the BMS protocol level. What choices do we have here? We can use any of the three most common ones; Modbus, LonWorks, BACnet. If we are in Europe, KNX is starting to be very important, but has small global penetration. Germany is a strong supporter of this protocol. KNX is very consistent and surely this protocol will change a control paradigm from three kings to the four kings of BMS.

When we are at the IP level, we can talk about network controllers. What is the task of network controllers? They are basically acting as application routers with an ability to apply business logic before rerouting a variable to another network or to the end device. What language to use at this level? Our experience with BrightCore shows that at server-side JavaScript is the best choice. All complex parts are written within hard core C or C++, and all easily programmed parts using JavaScript. This java script will not be processed within a web browser it will be processed directly at the server core level. In one of my past articles, I mentioned how that works within BrightCore.

Finally, after all the machine level processing, we have to interact with the hardware. From a perspective of exchangeability what we need is one common interface regardless of which BMS protocol we have beneath. Within BrightCore, we have been very conscious of that. Whichever protocol you have at the M2M level does not affect end user application or server outside the BrightCore. How is that achieved? Simply, by using our UCNP (unified control network protocol) as a general model where we keep all native specifics but at the level of integration, we use variables as normal variables connected to BrightCore objects.  These objects do not care about the origin of the variable. They just use that information as is, temperature, time whatever. That gives us the ability to reroute information from one network to other networks without a gateway, and to have all the time information about the origin of the information or service.

Still, this model is not good enough for interfacing machine data with for example, weather services. So what is the answer for that? What should we use in such cases? The answer is very simple - web services. I will explain how we used web services for access control applications. Why did we decide to use a web service for this type of application? There are a few reasons. We needed access database as part of the system.  We created Corelet with the embedded database which is exchanging information with real hardware as well as with the end user application.  That approach brings us a new view of the BMS infrastructure. There are no more separate vertical applications, everything is a network and interaction between real time infrastructure (controllers), and database applications is at the same level. This is almost the UNIX way where everything is the device. In our infrastructure, all edge devices are controllers, the database as well. 

How does that works? How does the end user interact with all this? We decided to use web services as an entry point for all interactions between an end user and the system.  There are a lot of articles written on how web services work so I will not address these issues here.

First, we tried to use SilverLight but after half a year we decided to wait for the next version. I hope version five will be really usable for such applications. Next choice was .Net. It is a really mature technology, and it can be used for such applications.
 
As we all know,  we must first connect to a web service through a WSDL( Web Services Description Language Services Description Language) file that is stored in some web server, and put that address into Service reference settings. In our case, we used Apache Axis2 technology. The server side is developed in C++.

Service reference settings

After connection, we need to determine a collection type which suits our needs for retrieving data.

Collection type

In the next step, we have to decide on certain methods and properties.  All these methods and properties are, in essence, representing an interface to communicate actions with the database and the control hardware. This is a principle of web services. It is a very powerful technology. Everyone who has access to WSDL could easily find out how to interact with all these methods. The next figure presents methods that we found out are needed for the Access Control system.  

Methods needed for Access Control

All this information is "machines ready" information, it is not intended to be used by humans. For example, a main object's structure looks like this:

A mai object's structure
After getting all this information, we can write our code. What language will we use? Any of the .net family in this case. Therefore, we do not need an application control engineer, we need a regular skilled programmer. This is very important, as moving out from a control world it gives us a number of benefits.

In next lines, I will just show how it looks in VB. Following figure shows how we do the instantiation of an object that represents the web service.

Visual Basic
And then, for example, when example,when we need to get door's data, we just instantiate, an appropriate door object,

Door data

to determine conditions that meet our needs. After that we can call GetDoors method, and result will be returned in an array of Door objects.

Door Objects
Now we can just fill in the data source property of controls that support object arrays like data grid control,

Access door data
or just iterate through it and do what we want to do with door data.

Door data

Executing methods that are not returning complex data like add, delete, etc. operations are even simpler to use.

Door data
As the access control is very much connected with the location, every door has a physical location. This is something what we do not have in the controller. It lives just in the access database Corelet. The location data we are communicating through “Location objects” which are loaded by calling GetLocationsAsync method, which requires parameters contained by LocationDomainCondition class.

Location domain condition
ParentID is an identification number of a parent location in hierarchical location's structure.
So when an asynchronous method is executed treeview of locations can be loaded.

ParentID

In the GUI (graphical user interface), representation looks like this:

Graphical user interface
To add a location we must call CreateLocation method with Location object parameter

CreateLocation
For deleting locations DeleteLocation method is one to be used with location id parameter.

DeleteLocation

Changing and updating locations data is done by UpdateLocation method with Location object parameter also.

UpdateLocation
Next very important object is Door (reader) object. These objects we use to interact with data from a door reader. These objects are loaded by GetDoorsByLocationId method with integer type parent ID parameter, which represents an identification number of door location,

GetDoorsBy

or by GetDoors method with DoorCondition parameter.

DoorCondition

When doors are added to the location by CreateDoor method, only parentID and door text must be set,other values have their default values until the user changes them.

Changing door properties is done by UpdateDoor method.

UpdateDoor
Controller and reader Id can be set by a user as well as reader name(text) property.
Set ID
Before the reader could be deleted from the database some issues should be resolved, like is there any user attached to the door, must be checked to prevent deleting readers that are in use.
Readers

Here is the list of a readers populated in listview control.

Here, I just showed one application, but it could be any other. We could do, for example, Lighting Control or interfacing with the Exchange server time schedules. The beauty of this technology is it is a very simple and fast way of integration between dissimilar systems and technologies.

In the end, we see that answering the question; What are the best programing languages for the infrastructure? is not really an easy question to answer. Through our work, we found that at the Controller level, IEC 61131-3fit us the best. At the network controller level and typical HMI level java script fit us the best. For the specialized applications, we found that web services with .Net technology programming language at the client side is probably the best answer.

All from our industry who are really open and look for fast and price affordable application creation, I am sure, will support my opinion that closeness of commissioning technology, and the programming languages has always been the biggest problem of BMS systems.  BrightCore framework tried to change the paradigm. To avoid a common "open“ control situation we decided to work with the information from controllers in a way to simply route it by core towards corresponding corelet (virtual control device). Such device has a web service interface and after that point any interaction is just a question of time and application programmer capabilities. Therefore, there is not complex interfacing or new technology to learn. 


footer


Lynxspring
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources