AutomatedBuildings.com Article - Understanding The Facets of “OPEN”

One of the most talked about subjects in our industry is that of “open”. And yet even with a volume of articles and commentary there is still confusion. I think much of that stems from not starting by defining what is meant by the term open. There are a number of facets of openness that affect building owners and those of us that work with automation systems. We can better evaluate whether a product meets level of openness we require if we start by categorizing the various facets of openness.

Facets of Openness

Device Connectivity. For many this is what leaps to mind when we say open. Does the product support accepted standard communication protocols at the fieldbus and enterprise network level. This would include protocols such as BACnet, LonTalk, Modbus, oBIX and Haystack OPC, Sedona – the list goes on. The real question is does the system support the protocol that I plan or expect to use in my applications.

Public interfaces. Are public interfaces, or API’s, available to enable independent third parties to develop complementary, external enterprise applications that can work effectively with the system. Can I integrate with other software applications that are important to me? Maintenance management? Can I develop code extensions that will run in the product itself? For example, can I write a communication driver to another system? Are the tools and documentation provided to allow for that? Or is that expressly prevented?

Access for Purchase. Where can I buy the products. Do I have choice or is it a very controlled distribution channel. After initial purchase what are my choices for buying products for system expansion - where can I buy these products?

Access for Service. In most cases, if I don’t like the car dealer down the street I can bring my car to another service center. Where can I get the product installed or serviced? How many suppliers? Is it an open, competitive situation? Or am I locked in to a single service company?

Open Database Compatibility. By this we refer to compatibility with standard databases. In other words can data from the system be easily stored in, and retrieved from, common database software used throughout my enterprise?

Open Source. Here’s a topic that often gets mixed in with the others when talking about open. The mainstream software industry has many examples of open source software. This mans that anyone can access the source code, download it and use it and extend it free of charge. A good example is Linux, an open source operating system. Another is Apache and open source web server platform. And then there is Project Haystack the open source initiative where a community of people from around the world are working to develop standardized tagging conventions to describe the data produced by automation systems, sensors and smart devices.

With open source, you and I can go to the community site for these technologies and download everything the community has developed.

Open Source refers to the process through which the technology is developed – an open community of volunteers, and also the license rights to the software. For example, Project-Haystack uses the Academic Free License 3.0. You can learn about that license here: http://project-haystack.org/doc/License. All software produced by The Apache Software Foundation or any of its projects or subjects is licensed according to the terms of the Apache License, Version 2.0. http://www.apache.org/licenses/

Overall there is much less occurrence of open source software in the BAS industry than is found in the mainstream IT market.

Marc Petock from Lynxspring states: The difference between open source and open system is an incredibly important distinction. “Open Source” refers to the coding behind software. Open Source allows developers to share, view, and adopt code to build new systems and so on. A good example is Linux. Open Source software is often developed through highly engaged, self-directed collaborative communities. Open Source software benefits from greater customizability, flexibility, and interoperability with other systems. With Open Source, the end product’s source materials are accessible to build a community of owners that improves the product through developing and enhancing the source code. “Open System” means that systems of varying functions and manufacturers can “speak” together through well-defined web services and APIs that are built into software pieces at both ends. Open Systems and the devices that are a part of them provide system-to-component connectivity and system-to-system connectivity. Open Systems offer ease of integration and customization without proprietary infringement.

Open Programming Language. This is a topic that Ken and others have written about in Automated Buildings. Virtually every BAS system uses their own programming language. In fact that is one of the key areas of differentiation where manufacturers have invested (and continue to invest) significant effort to create languages and tools to streamline the process of writing control sequences. Those languages only work with the manufacturers system. Control sequences cannot easily be ported from one system to another.

Toby Considine from TC9, Inc states: Open Systems and Open Source. You left out Open Specifications.

Open Systems: Someone can interact with it in some standard way, and get a hold of some information.

Open Source: It may be easier to get started, but can you add value? Some OS licenses require that any/all changes be contributed back to the project. Sometimes that is a hindrance to commerce.

Open Specifications: Is the API available and public. The IEC may charge you several Euros per page for a 400 page document. Their publishing standards award more pages. Their business model is free to participate, Pay to download. Others may charge to use. OASIS charges to participate, but the spec is free to download, free to use, free to sell products built using spec. Different SDOs have different business models, but all claim the term “Open Standard”

As we look to evaluate our needs for “open” and compare the “openness” of various systems and products it can be helpful to compare them along these lines to insure that we have defined the capabilities that we are looking for.

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

Events	Want Ads
Our Sponsors	Resources