Babel Buster Network Gateways: Big Features. Small Price.
Data World data never sleeps.
Nino Kurtalj, President,
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.
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.
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.
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.
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.
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
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
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.
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
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]