Babel Buster Network Gateways: Big Features. Small Price.
EMAIL INTERVIEW - Nino Kurtalj & Ken Sinclair
Nino Kurtalj, President, Elma Kurtalj Ltd
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.
middleware which sits between the building automation infrastructure and
Sinclair: What is BrightCore Framework?
Kurtalj: It is middleware which sits between the building automation infrastructure and horizontal and vertical applications. Typically building automation should be commissioned in any open and documented protocols like Modbus, LonWorks or BACnet. The aim of middleware is to normalize the information model between different application protocols. It opens simple commissioning as well as waste applications level integration through all enterprise, horizontally and vertically. It helps to treat building automation infrastructure (process equipment for intelligent lighting, HVAC…) in the same way as we treat databases. This particular approach created significant savings through the simple design process of “Energy Dashboards”, MTBF analyses for the process equipment in the building, speeding up of remote servicing, connectivity to ERP applications and human resources.
Sinclair: What makes your middleware different?
Kurtalj: It has a unique object model, comparable with for example Chinese ideograms. All Chinese people do not speak the same language but can read the same newspapers! Why? The same sign (Class) in different languages has the same meaning. The same is true with BrightCore. It has an understanding of all three protocols and therefore is able to translate information on the fly, and in real time, seamlessly from one language to another.
Furthermore, it has an open development platform, so a regular ICT person with programming skills will be able to use information from the building without understanding the lower automation languages. BrightCore has commissioning tools for connecting buildings. In the portfolio there are standard applications as well, but one can develop their own too. It is not just infrastructure for management of process it is at the same time infrastructure for management of devices talking different protocols. This feature helps in management of building automation networks.
In other words our product really answers the question: If your system controls processes, who is controlling the equipment behavior and how efficiently do these devices talk to each other?
Sinclair: What do end users need to do to be able to use your infrastructure?
Kurtalj: The owners will need to change their tender documentations on the way that all devices speak one of the open standardized application languages (LonWorks, BACnet, Modbus). In other words devices have to fully obey current US, EU, and Global ISO standards. As well, investors will need to request from contractors commitment that they will allow integration of third party devices like BrightNode. These devices will talk to the rest of the facility devices at the same level, therefore they will act as one of the nodes in the facility network.
There are other requirements too; eg allowing interconnecting this kind of device (BrightNode) into building application data logic. That means basically having crystal clear and well documented data properties as well as process behavior for of all devices in the facility network.
Truly this approach does not push the contractor out of the work after commissioning of the site. With our framework, the owner will have an infrastructure a little bit more accessible, exactly as written in the building automation standards. The competent contractor will still be needed. The automation infrastructure will stay intact in the sense of automation integrity, therefore the contractor will still be responsible for the process infrastructure.
The difference is that the results of the process will be transparent at the lowest level (wire level). This will significantly simplify hooking up of external service provides, and various application software developed through usage of standardize interface. The application developers will not have to care about what really is the protocol of choice for a particular building. Such an approach will significantly enhance the application market, and create a more acceptable price structure of the specialized applications as well as services. Furthermore, any refurbishment of the system will allow a true interoperable facility network in sense of brands as well protocols. This means that if the system is mostly using Modbus, one can easily do a refurbishment of the boiler room using BACnet, and in room automation use LonWorks. BrightCore will bring seamless integration of all structures. They will act as one entity. Essentially this is exactly the same process which happens during the internet revolution in 90s, at the transport (IP) level. As outcome we got more acceptable prices of IT infrastructure. We are sure that the same will happen with the building automation infrastructure. Further benefit is in having one system structure which manages remote buildings of any size. That definitely brings reduction in man power.
Sinclair: How does your middleware compare with conventional and existing solutions?
Kurtalj: Current way of integration of multiprotocol structures varies from integration of all existing devices in silos with proprietary structure through usage of gateways, other approach is to establish one of mentioned standardized protocols as the master protocol and the rest of protocols are connected to master protocol by gateway. There are systems which on the first look follow our approach, but if you really look at them you will find that they are more complex, not easy to use, and as well mostly are connected to native equipment protocol through gateways too. In all cases it is hardly imaginable existence of open independent application development space.
All these approaches are not really covering all aspects of multi-building and multi-protocol integration in the full sense. These approaches and frameworks do not have the simple Class/Object model as we do, and long training is needed so one can really use them. Some of them represent well established silos. Furthermore, we did not find any one who has a free open development kit. Therefore hardly any independent developer will develop usable universal independent applications regardless of protocol structure in the building. We did not find anyone with a Multi-protocol Commissioning tool which simply opens integration space to all of these application protocols, as well as third party applications and multi-building environment.
Gateway approach to talking remotely to the buildings is hiding what is really happening at the level of facility network. The networks stays closed and any problem at the communication layer will be seen when something definitely goes wrong. Therefore, we can not cure the cause; we cure the result of malfunction. That is always more expensive. BrightCore opens space for Dynamic Fault Detection at both levels, process as well as network communication level. We can say that one of the main properties is allowance to the control managers to enter into the system remotely at the device level and conduct the necessary distance diagnostics as the need arises in all of the protocols regardless of where the building facility network is located. Other approaches are generally locking mechanisms for the vertical silos of automation vendors, just in a bigger scale. Any third party application is hardly possible to find on the open market.
Sinclair: What are the product's key points?
1. Talks standardized building automation languages ( BACnet, LonWorks, Modbus)
2. Use secure encryption data transport of information over the internet (AES 256 Encryption standard)
3. All communication with buildings is at the Machine to Machine level.
4. It opens possibilities to have building with automation product from different manufacturers, even talking different languages, which are communicating seamlessly.
5. Create open competition between automation vendors through life cycle of the building. There is no vendor locking situation!
6. Open simple integration of ICT applications with building automation. The application does not need to understand complexity of building automation structure. These applications are accessing building data as ERP is accessing database. For the application, building automation looks like database.
7. It is globally the only independent framework for such purposes!
8. It could work on both platforms Linux and Windows.
9. It could works from small Din rail Linux devices to large servers.
10. It opens simple management of energy data and the integration into corporate horizontal and vertical applications. Therefore logically could be excellent in backing up government stimulation programs in real time.
11. Simple integration with Facility management tools with open interface.
12. Simple integration with ERP applications as well with other corporate applications.
Sinclair: Why you needed to develop specialized BrightCore infrastructure, why you did not just use the www?
Kurtalj: We see Web access as just one kind of application in the BrightCore infrastructure. The web is not event driven, so one can hardly get information when an event in the infrastructure happens. The web is good in cases when you have a situation like “Ask to Get” but will not work efficiently when you have a situation like “Get when happens”. Our infrastructure can work over Internet and intranet using both scenarios.
Second issue in managing of buildings remotely is a must in having proper security login structure and ability to remotely and securely change and maintain information structure. The ability to do so is a simple and fully secure task, everything is integrated into core structure. Our product does not send unsecure information over the internet. It uses secure encrypted envelope for all traffic, so there is no way that hackers could change the parameters of the building!
Sinclair: Who could be interested in your product?
1. The end user who has lots of buildings and would like to control all of them through an IP infrastructure from one service center, sharing the same competence in management of all buildings through the usage of expert groups (one group could manage all chillers in all buildings, another one could manage all generators, third one all UPS systems, and so on). All expert groups do not need to sit in the same place!
2. End users who would like to connect building data efficiently with their vertical and horizontal applications.
3. Big contractors (HVAC, Electrical) who have lots of installations and would like to lower their maintenance expenses, avoid vendor locking, and still provide first class services.
4. Facility management companies who would like to connect building automation infrastructure to facility management software infrastructure and lower subcontracting maintenance expenses and escape from single automation vendor price cage scenarios.
5. Energy management organizations who would like to escape from single vendor metering device approach, as well single vendor application scenarios.
6. Service providers who would like to normalize building data for their ICT services.
7. Automation distribution companies who sell open system hardware and need software solutions that can easily cover all types of open automation infrastructures.
Sinclair: Why do you believe that the framework will succeed?
1. It is a well designed platform fully compatible with today's automation standards (BACnet, LonWorks, Modbus).
2. It is open for adding new application protocols.
3. It has a simple approach to connecting and managing of the buildings and protocols (BrightCore Builder).
4. It can compete with big vendors in terms of functionality, price, manageability and speed of integration.
5. It could work on both platforms Windows and Linux.
6. Every user with rights can customize object model depending on his needs. (There are no predefined structures). That opens up a tremendous opportunity in problem solving scenarios.
7. It is exchangeable without touching primary infrastructure with some other framework tools.
8. Developed applications by an independent vendor could be sold in the open market. Therefore contractors and building infrastructures that use BrightCore represent at the same time customers and vendors for various applications who interact with building data.
9. All concepts are not going against contractors; it helps them to be more competitive, spend less time in building of applications and if they have something to offer there is potential to sell their applications at the open market. Generally, that approach will lower integration expenses. Time is money!!!
10. It is opening more business to skilled contractors through the application model since they are, at the same time, the one who understands problems, who are solving the problems, and through BrightCore they get to sell their proved software solutions to the much bigger market.
11. BrightCore is building market position with competence not with closed structure!
Sinclair: What is the market size for applications?
Kurtalj: Any large company with buildings spread over a geographic area is a customer for such solutions. Cities could use it to manage their buildings, as well as communities to manage their smart homes. We are estimating that there are 5000 buildings and spaces (public buildings, schools, office buildings, stores in buildings, sport buildings…) per million people that will benefit through remote building management in energy savings, maintenance schedules, tenant services, various billing services.
The price of integration is definitely a function of space size and type of services provided. Real business starts after integration. The established service will be significantly cheaper than the cost of having “building management experts” in every building. For buildings smaller then 50000ft2 building managers are too expensive! Most smaller facilities, if they are not part of a large corporation are not managed at all.
After integration, service becomes the continuous business of the facility service center, with an aim to help in lowering total building energy and maintenance expenses.
Numbers show that total set up costs will be paid in less then two months per building, and after initial investment the technical management expenses will go to ½ of the in-house management cost. Such service through proper and on time management of equipment will save, just in mechanical/HVAC costs, around $0,50 per ft2/monthly. In such service scenarios the building owner will have easy access to information about best usage of government stimulations, as well as other funding opportunities to lower operational costs. Furthermore, the organization will get full service center responsibility from legal point of view!
We believe that commercial factors like these will prevail and most technical operational management will be outsourced; part of them will use our infrastructure.
Sinclair: What is your market niche?
Kurtalj: Since the structure is absolutely open it can serve any size of building, and any kind of service. BrightCore comes between building technology and management applications. Through this unique model the upper layer applications are having unified connectivity to standardized building automation infrastructure. The best financial win-win effect per owner and service center will be shown in buildings sized between 10000ft2 to 250000ft2, although there is no limitation in size of building. Our infrastructure as a system acts as middleware between the building automation structure and systems like Access Control and Alarm Monitoring System (ACAMS), Networked Digital Video System (NDVS), Building Management System (BMS), Computerized Maintenance Monitoring System (CMMS), • Central Monitoring and Control System, as well Critical Points Monitoring (CMCS).
The platform creates a new level in centrally controlled facility management infrastructure. Such infrastructure effectively helps in control of all facility aspects. This new platform will become the cornerstone of the proposed service provider value proposition, because potential customers require a robust technical management environment with redundant control systems security, environmental stability, and effective maintenance.
The entire platform has been designed to be managed by outsourced Building Engineers which do not have to sit at each location. The function of the central service center is to provide a common point for technical management, facility network management, database management, and interconnectivity with experts, programming and redundancy.
Service Center building engineers are able to interface with the platform and the automated functions of the various application systems like CMMS system independently. Tasks that allow service call generation, escalation and resolution, could be handled without the participation of building management structure. That will create tremendous financial savings.
Sinclair: Do you use Obix?
Kurtalj: Obix is in development and will happen in version 2.0. Current version is 1.6. We were thinking to open interface just in Obix after version 1.5, but decided to create first Shell API interface in version 1.6 and then in 2.0 Obix BrightLet and Obix BrightNode will be added. Next in line is SNMP and after that OPC and KNX.
Sinclair: Why didn't you develop OPC first?
Kurtalj: Well, at this moment we can jump from any proprietary infrastructure with OPC to any of the protocols which are currently supported ( Modbus, LonWorks, BACnet). We decided to have a OPC gateway situation, since OPC only supports simple data objects OPC Items - Value, State, Timestamp, as well as information about the quality of data. We were more interested in moving forward with our class/object model which really helps in creating what we call facility objects.
ELMA Kurtalj ltd is the developer of the BrightCore framework suitable for integration with smart energy and resource management systems with open interfaces. BrightCore helps in technical management of small commercial as well corporate customers. It is an innovative solution addressing current issues in multi-building and multi-protocol building management infrastructure. It helps owners and contractors actively participate in reducing their carbon footprint, as well as energy and maintenance bills.
REPRESENTATIVE / DEALER - Posted May 31, 2010
Company: Elma Kurtalj ltd
Description: We are looking for representative for our BrightCore framework in US
Qualifications: Company with good understanding of multi building BMS market, BMS technology as well open system protocols like BACnet, Lonworks, Modbus
Notes: We are looking for serious long term partner for American market
Contact (email): email@example.com
Contact (fax): 385-1-303-5599
Contact (tel): 385-1-303-5555
Visit Website for more info (URL):
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]