Mashup   Data World data never sleeps.

Nino Kurtalj, President, Elma Kurtalj Ltd Contributing Editor

To be able to use such a possibility we have to have a very well developed data presentation model so we can easily integrate our building data, together with data from various services, into a common user interface infrastructure. The easiest way will be to use some RIA framework like Flash or SilverLight.  HTML 5 is just around the corner but still is not really here.

And here comes the question - why is that not easy? Why can we find very few open system installations, which are interoperable? Even when we have plugged many generally interoperable devices into a common infrastructure, we are totally lost without the vendor. A building integrated by one vendor will hardly interact with the building integrated by another vendor. We can even read data points but interactive services stay mostly closed, not to mention that to be able to add some policy to the points we need to have some metadata, which is generally not common.

The RIA frameworks are very focused on the layout. Very important is the look and feel of the interface element. People generally like nice things; most of the BMS HMI interfaces are really ugly being designed without any esthetic in mind. Those were good ten years ago but not now. Web technology opened the possibility to share building information seamlessly through the enterprise with people who are not HVAC or lighting experts. They expect applications which follow generally known rules of how the application should look. Use of the wrong principles can communicate the wrong message, and people will not feel comfortable using the application.

Another reason why we have to seriously think about RIA in BMS are trends towards Cloud computing. So, what is RIA? It is an internet application that looks and feels like  a desktop application. Since a client side application could have a state and work with data for a while it is very important to understand that fact.

We see Rich Internet Application as an interesting topic. It is totally changing our BMS scenarios as well as infrastructure. We need to move from the desktop concept of thinking towards the web 2.0 model, which decomposes our application into a set of interaction sub states, the exceptional states are specifying the default application behavior. State transitions are triggered by events on the graphical elements of the interface. Graphical Element class is generally an abstract model or template that could be decomposed into a set of Button, ComboBox, EditField, Grid or any other known UI graphical element generally called subclasses.

The GUI contains widgets that contain the state of the GUI screen. Having the state of the GUI in widgets complicates the way to get the state, and we have to put the presentation behavior in the view class. We can consider Presentation Model as an abstract of the view which is not dependent on a specific RIA GUI framework.

The presentation model is self –contained class that represents all the data and behavior of the UI window, but without any of the controls, which will render the GUI on the screen. To be able to do so we have to have data points ( properties) as well as states ( services). Since we have to present the data on the screen and that will be interactive we cannot  just do the screen synchronization we have to have key synchronization.  Through that concept together with events the web could really efficiently be used as part of BMS infrastructure. Fully capable of work in real time.

It is known that the domain entities, for AHU data sets are not designed with presentation in mind. They are really designed to solve business problems. That is the reason why we have to create  a new “model” designed with exactly a presentation in mind. However, also the model will only contain the data needed by View needs.

  Figure 1. General BrightCore model

What we can see in Figure 1. The model follows that within data Layer we first normalize specific Control application network Model to Common application model.

On top of it, we are able to add business logic through Class's programmable in Javascript through Builder interactive tool. The execution of JavaScript happens in the Core. The Class editor window is divided into three sections: properties, interface and script.

[an error occurred while processing this directive]The Property's box contains some standard class properties. The class name, the Stored and Read-Only properties and the class icon. The Stored and Read-Only property values only determine the default setting of these properties when an object of that class is instantiated. An Alarm object will, when created, have their Stored and Read-Only properties set to true. It is possible still to change those object properties later in the Builders Components editor for that specific object.

The Constants and Input boxes contain tables where all the interface items are defined. You can add, delete or move items by the tools on the left-hand side of the tables. The "name" column specifies the interface item's name who must be used when referencing the item in the script code. The "type" column specifies the type of the item - one of the boolean, number or text. When an object of a class is created, it will have the specified constants and inputs. Constants are objecting to parameters - they are set during the design of the system (in the Builder) and do not change while the system is deployed and running. The values of the parameters will be automatically set to the default values specified in the "Default" column of the Constants table. Inputs change depending on what is linked to them and can trigger a call to the class evaluate() method if their "trigger" attribute is checked.

Below is the script editor who contains color-coded JavaScript. There is a simple script error checker who warns you of an error in your JavaScript, including infinite loops, which would effectively block the functioning of script objects in the Core.

Adding a service layer between application and the system present the  window to business logic of the system. Furthermore, the service layer has the responsibility to communicate just the data what client needs.

Having such structure, with the SDK, allow us to integrate any building data to any application needed. What we see is that's open and known data and service model is „a must“ to be able to integrate the building data points and services with the applications from the cloud, and still kept the building infrastructure secure and separate.

 
Figure 3. Main Builder screen

What we can see at the left side is a presentation of the control networks. There could be as many as we need networks, any of supported types. At the central stage is the Component Editor, which is used for adding business logic on top of Control Network datapoins and services. Generally, we use the Mashups concept for integrating data points and services from various networks into the same classes/objects infrastructure usable through the Cloud model.

In other words, why translate the data from one protocol to another if we can process them all in the same script as well as return the data results back to the very network in native language.

Mashup mapping is totally changing the way we look at building automation. Creation of a presentation model on that principle opens the space for simple cloud integration of our buildings and integration of data points and services from the buildings with other services from the cloud. Generally, we are using data points and services as we use and work with the databases as data sources. 

At the right side of the Main Builder Screen, we can see the facility objects which are in reality produced pursuant to interaction with plug-ins like Vector Grahic plug in, Time Chart plug in, Alarm or schedule plug in. We can easily add new plug-ins too, under our requirements. It is very important to understand that what we will communicate with the Clients will be just the View information not the actual graphics screens.

  
Figure 4.  Graphic Client - HMI

All information between the server and the graphical client is exchanged through a service layer which is on top of the business logic layer. The service layer is responsible to communicate to domain model or business logic, and it passes just the data the Client needs. The service model knows about the domain model, but the domain model does not know about the service layer. As well the presentation layer – client, only knows about the existence of the service layers and about used services.

The Client is not aware of the domain model. What does that bring to us? Dividing the business model as well as the presentation model from the data model we can upgrade parts of the building automation system with not just other vendor products. Furthermore, the products/components could speak another language, and could be commissioned into the system as another network as well.

At the level of the facility objects, we will not notice any change, since the data point and services from the new network will also be bound as the previous ones. Therefore, changing devices and protocols will not require complex engineering of the system. Through such an approach the buildings could really meet the Cloud computing and Data's world that never sleeps.

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

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