AutomatedBuildings.com Article - Open Automation Object Model

Are you ready for change?
Open Automation Object Model (OpenAOM) will enable programmers throughout the world to program building automation devices from a common object model. It will engage the programmer in the automation industry without necessary knowledge of controls drawings and engineering specific diagrams.

What is OpenAOM going to be?
It will be a standard form of creating automation objects which can later be used in automation applications.

How is this standard going to be formed?
Through OASIS and interested industry partners.

How will OpenAOM change the industry?
There are actually a couple of reasons why it will change the industry. The main reason is that a programmer will be able to program devices without the need of control drawings. Programming will be created on a layer above the actual points with generic xml object context. The context can then be linked to the actual points. Programmers will be able to focus on what they do best which is programming.

The Automation Industry is changing rapidly. We need better tools for programming automation devices. Open Automation Object Model will enable us to have programming and documentation done in one standard format and location.

Could you explain how OpenAOM will help with documentation of Automated Devices?
First of all, OpenAOM will be a standard for input and output devices that can be used to build submittals, programming, engineering tools, etc.

Why do you think there is a need for a standard like this?
Actually, I was looking into a way to make programming easier and jotting down ideas on the way to ConnectivityWeek. During the meeting, I attended OpenADR (Open Automated Demand Response) conferences and started to understand how standardization works. Laurant Liscia from OASIS (Executive manager) was resolutely explaining the standardization process. In one meeting, ASHRAE’s president elect at the time was pointing out the need of standardization processes like BIM (Building Information Model). At that moment, I realized the need of an open system like this. I introduced the idea to Toby Considine and Laurent Liscia and received positive feedback.

In my opinion, the need of an OpenAOM will be seen when systems like OpenADR come into play. That is when utility companies will try to save energy by limiting demand, modifying temperatures on thermostats, ramping down VFD’s or dimming/shutting off lights. We will need programmers to make those changes to the BAS system. Without a standardized set of tools to communicate to the BAS, programs will need to be commissioned from the BAS technician level. If we have a standard application like OpenAOM, these sets of applications can be programmed from the utility or engineering level and can be handed to the BMS contractor for commissioning.

Another reason why we need a standard is that the technology that we use every day is changing rapidly. We have seen vast information changes and tools like M2M. Automation devices that are connected are increasing not only in the amount but also in the types. We have phones with different operating systems. We have standard building protocols. But, they are not programmed in a way that would make it easy for programmers to write code that would enable properties from a cellular phone to be passed to another automated device.

Please email the following paragraphs, along with this interview, to any interested parties. We are trying to find sponsors in order to open a chapter in the OASIS community.

I am looking for people interested in developing a standard XML-based vocabulary for device centric automation and control, initially for use in programming Building Automation Systems (BAS). The work will be known as Open Automation Object Models (OpenAOM).

Current methods for cataloging components of an automation system are proprietary. Programming methods are often too low-level (lists of points) to work with without referring to external diagrams and documentation. Configuration and operation of automation systems often use different interaction models. This adds complexity to installation and configuration of systems and makes building system commissioning difficult, expensive, and often unverifiable.

A common framework for describing and programming low level automation objects would enable standardized commissioning and encourage the development of higher functionality system configuration and automation programming tools.

Today, every automation company is repeating tasks every time but the devices do not change. While specifications change slowly, the underlying code may not change at all. If we are able to create a framework for lower end controls that supports advanced functions, it will help the automation industry, improve outcomes and accelerate innovation.

In the automation industry that which needs to be controlled does not change. It is either based on temperature, pressure, measured gases, or occupancy. These are the event parameters of the code. This initiates part of the function. These parameters can be easily selected, dragged and dropped on a canvas and can easily be commissioned in the controller. Once we are done defining our events, we need to define our control object. These are Dampers, Valves, Fans, Coils, and Compressors. Our events will dictate our control objects. There will be a parameters section on the event objects which can be animated and the links can be made right from the canvas.

Such a standard may also enable “plug and play commissioning.”

If you are interested in discussing these issues please contact signup@OpenAOM.org. The current goal is to discover if there is sufficient interest to form an OpenAOM Technical Committee and create an OpenAOM standard.

Events	Want Ads
Our Sponsors	Resources