Open access to vendor control languages Or more control, less vendors.

Nino Kurtalj, President, Elma Kurtalj Ltd Contributing Editor

Articles

Interviews

Releases

New Products

Reviews

Editorial

Events

Sponsors

Site Search

Newsletters

Archives

Past Issues

Home

Editors

eDucation

Training

Links

Software

Subscribe

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++.



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



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.  

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:

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.

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

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.

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


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

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

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.

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.

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

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

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

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

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,

or by GetDoors method with DoorCondition parameter.

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.

Controller and reader Id can be set by a user as well as reader name(text) property.

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.


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.