There are a lot of questions which are raised every time we are in a new build development, or refurbishment. One of the critical issues is: When should the BMS design be developed? Before or after the MEP packages? Asking such a question is almost the same as asking: Do I cook the potatoes before, or after I grill the meat?  The real answer is that we have to do it with proper timing so that everything is ready to be served at the same moment. The building design process is very complex, multi-disciplinary work and every error will cost an investor through development as well as through all life cycles. Therefore, building automation and management design should be carried out in parallel with the building services and elements.

[an error occurred while processing this directive]

[an error occurred while processing this directive]

One of the key drivers today, conservation energy strategy, plays an important role in achieving energy efficiency. Energy efficiency does not have a static dimension, it is a dynamic process influenced by people and technology behavior in the building, as well with the building itself. One of the key changes what we have to accept is that all technical subsystems in the building are interconnected and represent a large network, where among technology the users represent the node of the network in addition to the building. We cannot gain true benefits from integration, unless we design systems in parallel and take into account interactions between nodes.

This understanding tremendously moves the building automation design concept towards Information and communication technologies or ICT network design strategy, where standardization started fifteen years ago with structural cabling standards. Today we have to anticipate a new kind of network in the facility - The Facility Network. Therefore, that particular network has to be developed before the building automation subsystem details. As we know it is rarely possible to have a single language (automation protocol) used in all technical subsystems in the building. History is just too heavy! Therefore, sizing building automation devices on top of one or two protocols is a small step for the engineers, but a gigantic move for the industry. Any of the common automation languages will do the job ( BACnet, LonWorks, Modbus) all have IP capabilities as well as good device interaction at the field bus level.

What are the parameters to be considered in design of such a network? We really have to consider everything by focusing the design through the perspective of the end user, and the owner of the building. Simply, we have to find the balance between the standard of living and operations. Today technology can do almost everything we need and can imagine. The harder part is to maintain the same quality level of operation efficiency and vendor agnostic. The final design solution should be environmental, economical, reliable, maintainable and technologically acceptable with an open path towards future expansions of the system.

How to put all these requests together, economically, reliably, and stay maintainable? The key issue for the owner is to keep expenses as low as achievable. Having the network as a spine of our facility opens the possibility to interconnect facilities to one large facility internetwork. This is a proven way of cutting expenses. The possibility to share expert knowledge across all our facilities brings tremendous saving potentials.

Unfortunately, after we design our building and inter building network the installation process opens new issues and numerous problems arise during the deployment. More or less the installation process is like building the Tower of Babel. The contractors of various systems are not sharing the same culture and view of the project. Sometimes the communication between them is very difficult as well as project execution. These differences are seen mostly through their appetite to keep exclusive control of their subsystem. The interconnection from their island with other subsystems should be addressed through the protocol converter, and YES they have to have their Head End monitoring station! Such systems will work, but it will raise the price, and we will get another single point of failure. From the risk point of view, the security of operation will be downgraded, the maintenance will become a big pain as well as keeping of the spares, training, etc...

Such design will give us a false image of a fully integrated system, but experts knows it is not enough just to have common data presentation capabilities of all subsystems within one user application. We have to be able to interact with the subsystems managing both the device functionality as well the process. Doing it through the classical BMS/SCADA approach after few buildings the limitation on one control network with ad- hock gateway thrown in order to translate another presented network will raise the expenses and the multi-building infrastructure will become a big expense for the owner. Since, the applications in such structure are not specialized, and each has a complete set of tools from mapping, graphics, charts, scheduling, user management, etc., the owner is always overcharged. Adding specific user applications from the market is not really possible in such structures.

The management of these building can be mostly assigned to a few people, all monitoring the complete building. Inability of such a system to scale well is keeping owners of the buildings in the vendor trap. It is true that the classic BMS can provide the connectivity to the multiple buildings as well the various features, but the manageability of such a system falls rapidly with its complexity. There could be numerous subsystems and therefore, numerous gateways connected to the main system. Each gateway has to have its own mapping to enable the communication between networks.

To achieve a workable Building Automation & Management System suited for multi-building structure we have to be able to encapsulate control networks. Regardless of their type, they have to be encapsulated in the way that all native protocols could be translated to one common "super protocol“, but the data from native protocol should not be masked behind applied virtual variables within the gateways.

Generally, that means that the right way of integration is through the network model approach!  LonWorks and BACnet are nice examples of BMS network infrastructure. Creation of such a common control network abstract model and the design of common automation objects which keep all protocol specifics simplified the multi-building an inter-networking solution. Following that concept, we are able to integrate various protocols without usage of MPC devices, in other words, information flows from one protocol to another through objects and there are no classical gateways between the systems. The Super Protocol acts as a real time highway between networks allowing the object and variable level traffic between different networks. The information travels in the form of an object unchanged through the network keeping all properties and the information specifics during the transportation.

In the operation level, it is possible to integrate the information from the device living at the native network to the device living at the companion network without stopping the system. Furthermore, it is possible in the same Process Container to perform processing of the information provided by data from various networks. That process could be delivered at any level or instance: M2M ( machine to machine), M2S (machine to server) or M2A (machine to application).

Such principle is more effective than translating the information in the gateways. We can assume gateways as static entities. Packaging the information and their processing at the place of usage in the object containers generally delivers requested dynamic functionality needed in multi-building installations. Regardless of where the information is processed, at the M2M, M2S or M2A level, the multi protocol object translations could be done and still the network manageability could be kept. Networks built on such a principle open the space for the specialized applications which will provide the best process results.

Still, most currently built infrastructures are manufacturer centric. Most control system manufacturers are able today to provide an integrated solution. Today there are defacto and dejure global standards, like LonWorks, BACnet, KNX and Modbus. These standards are well described through US, EN, ISO norms. Therefore, we can say that the language of communication between devices is known as well as communication principals and exchange of information.

Such practice disables the ability of the middle wares like BrightCore to touch system functionality and open infrastructure to specialize independent holistic third party solutions.

We see that the key battlefield is in who provides a control language at the device and the network system level? If the control language is left exclusively to the single vendor the middleware could just be used by an existing manufacturer to migrate from a competitor's product to their platform and the owner will not see a real benefit from an open system.

We can imagine the differences of the application languages as differences between human languages. For example, most readers will not understand this: "Bunu anlayamıyorum eminim ". In this example, we can read the letters but not understand the meaning of the information! This is usage presentation of the same communication media "written letters", but not the usage of the same application language. More or less the same we see in the automation. The devices could talk over the same media but usage of different application languages is not allowing exchange of the information content between speakers. In most cases the dominant application language will be used as the main language and the other languages will be translated to one common language, these translators are called gateways.

Therefore, after a move from proprietary vendor solutions to the standard application language solution, the mix and match of the different vendor devices is possible if they are compliant with the particular used standard. In the most cases LonWorks, BACnet, and Modbus from different manufacturers will coexist on the same network without any problem talking to the same peers: Modbus to Modbus, LonWorks to LonWorks, BACnet to BACnet. To exchange information between for example Modbus and BACnet a translator will be needed.

At the device level, we can assume there are two types of devices - programmable and pre-programmed. Common programming environment (language) for programming of programmable devices is an additional request at the network level to the application language. The existing (International Electrotechnical Commission) IEC 61131-33 programming environment is used by a lot of vendors as a control language within the device. Pre-programmed devices are the ones which will be just commissioned to the network. The commissioning process is basically the creation of the automation M2M ECO system. It is a process of building the system scope and environment. As commissioned all devices are aware with whom they have to exchange information.

For example, LonWorks eco-system will be created with the LonMaker commissioning tool. After creation of the system, the automation system will be able to operate. For such a system, it is not important who is the vendor of a particular device, it is important just that the device complies with the standard and can communicate with other devices on the network. For BACnet the process will be more or less the same. Such open system concepts move the facility network to a truly multi vendor structure and change the responsibility and competence request level for the system integrator.

In the case of BrightCore design as a middleware between the standardized application protocols, there are proxies (BrightNodes) which keep native application protocol specifics intact through the whole information transition. BrightCore essentially recognizes two types of objects - simple and complex. Simple objects are called Proxies and have one optional input (optional in the sense that it can be left blank). Complex objects have one or more parameters and one or more inputs. Furthermore, their behavior is defined by a script (written in the JavaScript language). The definition which defines the parameters, inputs and the script is called an object class. The result of these scripted objects depends on the code in the script. These objects are an extremely powerful mechanism. BrightCore does not define what an alarm is, for example. There is an Alarm class which defines alarm behavior, and it can be freely edited in the Builder's class editor.

Data is handled within the object data processing unit - The Core which follows the object concept. The objects are data processors, and they reside in the Core. The Core also has an embedded database where the object values can be stored, if requested. With such an approach BrightCore fully opens the M2M infrastructure to the ICT applications' world and principles. The building automation device's network from the ICT point of view is seen as a database.

[an error occurred while processing this directive] There is no need to translate native building automation languages until there is no processing need in the Core. There, within the same object through the java script the information from different application languages can be mixed without translation to a common language. During the usage of that information (for example a temperature value) it is possible to get the exact origin of that variable, and at the same time mix it with variables from another application protocol like BACnet and Modbus, as well as ones which are from Higher Altitude Systems in the same processing container. The final information output could be in any of the understood application languages, as well Web service, or oBIX.

BrightCore is a typical middleware, but with the difference that in any usage the native network properties will be accessible by any point in the system ( M2M, M2S, S2A). As such it is not intended to be used as a vendor migration platform, rather as a tool to keep building automation system vendor and protocol agnostic.

For example, if we have a LonWorks network, the connecting node between LonWorks and BrightCore will be the BrightNode. The node will be commissioned together with all other LonWorks devices by the same principles. When the LonWorks variable will come to BrightNode it will be packaged and transferred towards The Core server as well the applications. The information background will not be changed like in the gateway.

This is really the best way to process the data, keeping it in the native form! In BrightCore, the common processing containers bring the possibility to transform data from one manufacturer system to another, without losing the identity of the data. Through such a strategy, BrightCore is not really a proprietary system, it is more like application envelope, which always delivers natively understandable information. BrightCore does not change the way the native network is handled. The contractor deals all the time with the domestic known system, and BrightCore is a just asynchronous message delivery system with the translator included at the smallest bit of delivered information.

All this makes BrightCore different from other systems and middlewares. Among others the main difference is its designed expandability. By design we meant not an additional feature but set as a core design specific right from the start.
The system wasn't designed to talk to a single control net (eg. LonWorks) and then with an added functionality for others (Modbus, BACnet...) - it was designed from the start to talk to any control net for which there is a BrightNode. There is no "native" control net for BrightCore. BrightCore brings the expandability right on the control net layer. There are no native clients either. The system has an API (Shell), and all clients (BrightLets and CoreLets) use it to access the system. That is expandability on the client/server layer.

There is also the matter of control net data processing. The processing is done through "objects", and the processing details are defined with object classes. BrightCore does not define what an alarm is, for example. There is an Alarm class which is not built-in - it is created in the Builder (the system's configuration editor) as any other class would be. Any class can be created, and thus any data processing can be achieved without adding new system components or changing existing ones. That is expandability on the object (data processing) layer. This expandability makes BrightCore an open system (freely "developable") and opens up more possibilities than traditional automation systems, especially in cases where there are requirements for data, which are not user centric but more servers centric.

BrightCore handles this kind of situation in a special way. For example, we point to the Access Control subsystems where there is the database with users and rights, which are applied indirectly to physical hardware. The Core system consists only of the above mentioned components. However, as clients are not pre-defined but rather independently developed using the Shell API, the client layer can host all kinds of supplementary systems, which accommodate any mentioned situation.

The mentioned Access Control example is resolved in the following way:
A heavyweight client keeps a local database of users and their permissions. That client has to be able to access the system in order to obtain object IDs so users and objects can be linked in permission groups. The client can do this through the Shell API. We call these clients CoreLets, since they have no users, they are autonomous and more server-like and without direct human users. Other lightweight clients (BrightLets) communicate directly with The User Permissions CoreLet to obtain information on users and their permissions.

There are various requirements for which CoreLets are the ideal solution. One such requirement is having a shared database of animated vector graphics for showing on the lightweight (human user) BrightLets.

The concept of CoreLets allows for a better structured system, where things are kept exactly where they are needed and not bundled into one place. Such distribution of information helps in cases when the system starts to grow, and the balance and redundancy become key risk factors.

CoreLets, like BrightLets, are programs, which use the Shell API to communicate with the Core. Description of the CoreLet and explanation of their functionality is easier done through some scenarios.

A basic scenario would be the one revolving around alarm notifications. In BrightCore, alarms are implemented as objects of the Alarm class, and as such they are executed in the Core. This scenario requires the following components:

1. A Permission CoreLet, the database which holds information on users and their permissions. The permissions are implemented with groups. Each group has users and objects. If a user and an object are in the same group, the user has certain permissions on that object.

2. A BrightLet which edits the database - creates users and groups, and assigns users and objects to groups. This Brightlet is a GUI application for a human (administrator) to assign access permissions. This is a "passive" Brightlet because it uses the Shell only to read the object structure so it can put those objects into groups.

3. A Notifier CoreLet which uses the GSM or e-mail layers to send notification messages to users when an alarm goes off. This is an "active" CoreLet because it subscribes to alarm object changes and reacts to them. The Notifier CoreLet has to check all permissions for all users, so it can send the right notifications to the right users. Users without permission on an alarm object shouldn't be notified of its changes.

The piece of code which reads user permissions from the permissions' database can of course be encapsulated and be used in any CoreLet/BrightLet as a widget.

Another important component of the system is the BrightNode and their ability to talk to, for example, LonWorks network. It is the big difference between BrightCore and typical BMS with OPC or LNS centric access to LonWorks. The LonWorks BrightNode is commissioned into the network as an ordinary LonWorks device through LonMaker. All variables which are used by the BrightCore system are bound to the device (fan-in connections). When in operation, the LonWorks BrightNode uses its Lon stack to receive updates from bound variables, the result of which is a very low network traffic footprint. Compared with typical approaches, which poll the network for variable values generating network traffic with each poll, our approach is much more efficient and uses much less bandwidth.

With Modbus, BrightCore talks in a different way. The Modbus BrightNode communicates with one or more Modbus hosts, each of which has a set of Modbus devices. Unfortunately, Modbus devices are somewhat simpler, and they don't have the variable binding feature of LonWorks. BrightNode has to poll all used Modbus variables for their values in pre-configured time intervals. These need not all be of the same length - variables which change infrequently can be polled less often. For example, temperatures could be polled every 150 seconds without significant data loss. Other variables could be polled even less often than that (power consumptions, etc.).

The CoreLets could talk to each other, and they do not have to pass information through the Core. Truly there is no need to hamper the Core with inter-client communication, after the initial handshaking (seeing who is where) is completed. The handshaking is done through the Core, but after that it is direct communication between components of the system.

In conclusion we can characterize issues in the facility inter-connectivity.

Generally there are operational challenges like: Transition, Coordination and alignment, Program Management and Change Management. There are technology challenges too: Integration, Obsolesce of Technology, Enterprise Solutions, Remote Monitoring and FM Integration.

We can conclude that the main and the biggest difference between the BrightCore and standard solutions is that most of the currently used systems are SCADA kind PC based solutions. So, the single point of failure increases, secondly many drivers with multiple layers of data translation make such a solution unstable and complex. Thirdly, these solutions are the silo type of solutions - hardly expandable. BrightCore is built to totally use the power of open protocols and follows standards without artificial boundaries created by automation history.

The intention with BrightCore is to remove the single point of failure from the system. This particular principle is more or less delivered through the M2M layer as well as through the M2S (machine to server) layers. Unfortunately, it is hard to avoid the server layer, but there could be redundancy and the servers could be managed in the data center manner. Such a principle generally raises the availability of the system to telco 99,999 reliability. Furthermore, as the integration and commissioning are split from operations, the system management becomes routine. Therefore, it could be hundreds of networks connected to the Core Server infrastructure. Within BrightCore, it could easily manage a multi-vendor, multi-protocol network infrastructure with more than 40000, I/O.

BrightCore is changing the way the building could be integrated and commissioned. There is no need to be bothered with brands any more. Embracing BrightCore into the infrastructure creates the switch from the vendor centric concept to the protocol concept and still keeps a high standard of process automation. Within the Protocol Concept every device is exchangeable. The BMS industry finally reaches the transition stage as ICT did twenty years ago. Still, the comments from a lot of consultants and vendors are just the same as the comments of ICT vendors and consultants in the dawn of the Internet protocol. The answer to their question, "Which Vendor is the best?" is the same as the ICT industry answer from 1990 to the question, "Which mainframe is the best?" Forget the vendors use the open protocol standards!

Does anyone still remember the names UNIVAC, Honeywell as a computer manufacturer, Burroughs, Control Data Corporation, General Electric, NCR, RCA? Nowadays, it is possible to purchase a BMS system the same way as we purchase ICT equipment. To be able to do it all we need is to follow an open protocol paradigm like LonWorks, Modbus or BACnet.

Our System Integrator division integrated around 2000 controllers at 10 geographically distributed sites (30 000 I/O) connected in a single inter-network, and the network is still growing on a weekly basis without performance erosion. Currently, there are 25 different manufacturers in the network talking LonWorks, Modbus, and recently BACnet. New vendors are integrated into the system every couple of months. The current owner of the infrastructure established just one single rule. The programming tools should be available as off the shelf products from an independent automation distributor. If there is some special "partner" requirement, the product will not be accepted and commissioned into the network. The open protocol concept happened after they have been overcharged by contractors and BA vendors during an operation lifetime. They understood that following an open protocol concept created a request for a skilled and reliable Building Automation System Integrator but in the same time lowered the automation vendor dependency. This approach gave to the interchangeability another meaning and scope.

About the Author

Nino Kurtalj is an experienced senior executive with a more than 20 years in the communication and building automation business. He is one of the pioneers in deploying Open System (LonWorks, Modbus) automation building infrastructure in Croatia and the Mediterranean area. He guided his team in successful automation, based on an open system paradigm, of facilities like data centers with  more then 20 equipment manufacturers spread over various protocols and more than 1000 devices. His team has experience in automation of buildings sized up to 300000ft2 with up to 2000 devices, integrated in a single LonWorks network. Six years ago he initiated development of BrightCore framework which was awarded with LonMark's international software product of the year award last year at LONCOM2009.

The base for that development and achievement was the new LonWorks software stack which could transform any IP device with OS to IP LonWorks device that could be commissioned in standard LonWorks commissioning tool. The stack is developed in Elma and currently works on both platforms Windows and Linux from small DIN rail embedded devices to big 19” rack servers.

Mr. Kurtalj was participated as a speaker in events in Europe as well in US and Middle East. He was a speaker during Connectivityweek2009, as well as RealTech Middle East 2010.  

[an error occurred while processing this directive]
[Click Banner To Learn More]

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