What defines an open system in the context of building automation?
Published: 2020-05-19 21:52:15

**A key feature in the the decision making process of a building automation system is the request for an open system.** 

The definition of an open system is heavily debated in the building automation domain because in the modern days the digital transformation processes now involves people from new domains with a different point of view than traditionally. Some say that open source code is a necessity for a system to be open while some say it isn't. Let's dig deeper.

If we start by looking at our human body and investigate if that is an open system we *truly* can say it is. Matter can enter and exit the human body freely and we allways produce an output from what get's input to the system. If we look at the human body in the context of software it means that the software should have soft boundaries that should be easy to identify, investigate, understand and allow for exchange. A closed system would have hard boundaries and allow for almost no exchange. 

The widely most acknowledged software being named as truly open is the **Linux kernel**. Most of our devices today use Linux. It is distributed as open source code which means that you can actively read and contribute to the project without having to be employed by a specific company. You can also create your own version if you follow the restrictions that might be implied by the license it is distributed with. 

**But does and open system need to have it's source code to be open for everyone?** 
I think not. 

There are other things that would define a building automation system open even though it might contain proprietary protocols and is closed source. Alot of people tend to focus too much on the term *"open source"* just because it has the word *"open"* in it and cannot always debate on why a system needs to be open sourced to be acknowledged as open. 

**Some say that an open system is defined by three key factors**:
* Interoperable
* Portable
* Open standards

**Interoperable** meaning it has the ability to interact and communicate with other systems. 

**Portable** meaning it can run in many different envorinments. 

**Open standards** mening it can be freely adopted, implemented and extended. 

I agree on these three key factors beeing what defines an open system in the context of an open building automation system. Just by implementing support for **BACnet, OPC Ua or Modbus** you have designed a very **open and flexible** system looking at those key factors mening that **most of the systems out there today are open**. Of course they also differ in what level they are open but they are all open in some way.

My experience is that this causes alot of misconception because in the digitalization process the people from the software engineering domain are **not familiar with these different communication protocols** resulting in false statements that the systems are not open. Their idea of an open system is one that has the ability to extract, inject and manipulate data externally **in a way that is more common for them like API's, SDK's or telemetry protocols**. Maybe the right definition would be an **open IoT system** for this rather than a **building automation system**. 

The conclusion is that the misconceptions around open building automation systems is mostly because people from different domains of expertise have **different definitions of what is open**. There are not as many systems that are open from a software engineering perspective as there is from a building automation perspective. **What is often referred to as an open building automation system is probably more aligned to an open IoT system**. 

I'm very curoius to hear your personal thoughts of what makes a system open in this topic in context of building automation, let me know in the comments below!