Frequently Asked Questions
Why did the participating organizations create IP-BliS?
IP carries different protocols which can also be applied to building automation. There are several reasons why IP will become the dominant protocol in the area of building automation. By joining forces, the organizations of IP-BLiS can convey the same future-oriented vision to their members, i.e. to converge towards using the same transport (IP) and the same security mechanisms, regardless of the diversity of application layer protocols or different approaches of the ecosystems. From a marketing perspective, by defining a common transport and security requirements together with one voice, IP-BLiS can represent all manufactures in the building automation domain.
Will IP-BLiS create a new technology specification?
No, IP-BLiS is not writing its own specification. IP-BLiS may gather requirements and relevant standards from the market - security, for instance - but each participating organization is responsible for specifying its own technology. If any gaps are identified, IP-BLiS will highlight this to the appropriate member organization.
Existing standards like KNX and BACnet have been around for a long time and are already moving to IP. How will IP-BLiS accelerate the transition?
IP has been in building protocol standards for a long time. Thousands of installs already have IP. Historically, IP was thought of as protocol specific (like BACnet/IP or KNXnet/IP) instead of IP with BACnet or KNX over it. IP-BLiS will help change that perception and conversation
The objective isn't to converge application protocols but to enable them to coexist. Why is this the best approach for commercial buildings?
Similar to what happened previously with computer networks, applications became less relevant than convergence on the same transport layer.
What are the goals/activities planned for IP-BLiS over the next six months?
The goals are to establish secure IP as a solid future-proof technical solution and create materials to support this, to indicate which security requirements fits best for building IoT, and to investigate the possibility of proving co-existence of the (IP-based) technologies on the same network.
Some participating organizations are more established than others in the building automation market, does this matter?
No, the goal is to have a unified message that all participating organizations endorse IP while allowing companies to decide which solution or solutions works best for their business and use cases. Participating organizations are not limited by any single market segment and their members are also active in various market segments, including building automation. This ensures that if manufacturers of different organizations approach the building automation market, their approach is unified.
How does IP-BLiS promote coexistence?
Video, phone, file transfers already coexist on IP so at the technology level coexistence is automatic. Similarly, multiple building protocols can coexist on IP. IP does what it should. It is not broken so IP-BLiS does not need to "fix" it. What IP-BLiS can do is educate the market, demonstrate coexistence, and identify common tools and procedures to simplify deploying, provisioning, and securing complex building systems.
Given coexistence, what else is needed? Security?
In addition to creating awareness among the different manufacturers, IP-BLiS will also agree on common requirements for network layer security so that building administrators can rely on the same requirements, regardless of which application layer is used in the building automation product connected to the IP network.
Four of the founding organizations, OCF, KNX, BACnet, and CSA all have mature application protocols. Will IP-BLiS create a new protocol? IP-BLiS and Project CHIP have similar goals of migrating control systems to IP. Project CHIP is consumer-focused while IP-BLiS targets commercial buildings. Is IP-BLiS as the commercial building equivalent of Project CHIP?
No, it is establishing co-existence on IP of those protocols. Due to IP it will be easier to use multiple protocols in a deployment scenario, avoiding specific hardware needs, and the integration can be done on application/software level. Also the same device hardware and network infrastructure can support multiple protocols.
How will IP-BLiS affect costs? Specifically, device costs, deployment costs, integration costs, and operational costs?
Reduces tool and training costs for building owners and operators. Improves operational efficiency and effectiveness. Suppliers lower cost through fewer products to support and simpler system integration.
How can I participate in IP-BLiS?
You may participate in IP-BLiS if you are a member of one of the participating organizations.
How is IP-BLiS positioned vs Fairhair Alliance?
Fairhair Alliance is part of OCF which is part of IP-BLiS.
How does collaboration between the organizations work?
There is a liaison in place and in order to participate you must be a member of one of the participating organizations.
What is the IPR policies?
This is defined by the individual organizations. IP-BLiS is a market interest group.
If there is no IP-BLiS specification, will there be a need for a certification program? A logo? If not, how do you ensure devices based on IP-BLiS are interoperable?
IP-BLiS might set a common set of requirements, but the participating standards organizations will define the different technical aspects and choices.
One benefit of IP-BLiS is "common security in building networks." IP-BliS is not defining technical specifications so how will this be accomplished?
You cannot deploy IP-based solutions without good security. But there are various myths that IP-BLiS can debunk. All applications will use the same IP layer, the security might be different, but that can be solved by software, the requirement level will be the same. Investigations on requirements level are being addressed (ENISA/NIST).
”Common semantic interpretation of data ... independent of application protocol" is a potential benefit. Has the industry moved beyond thinking that full-stack convergence is required?
Yes, this enables application level convergence because all applications will run on the same IP network. Semantic translation can be a software function on the network. Each application framework has its own strengths and it will be difficult to converge to a single application framework that can do all necessary functions. This is leveraging all application protocols. The benefit is for the end user, they can choose which application layers will fit their needs and this will result in cost effective product offerings. Convergence works best in an evolution process. IP allows for that. Moving to IP will create more integration needs among the application layers. Semantic interoperability will be the next hurdle. The first goal is getting to IP, easing the way for application layers to talk to each other.
Do you intend to address the "provisioning problem" - securely connecting new devices to building automation networks? Will device networks like Thread have to change their onboarding methods?
Yes, getting on the network will be determined by the network layer. Due to the sheer amount of devices there will be a need for standardized automatic onboarding procedures. IETF, WiFi, and Thread can be the basis for this. Application layers will need to adopt these mechanisms. In short, there is a difference between getting on the physical network and doing the security at the application level.
Specialized gateways are needed to translate non-IP devices protocols to IP so that applications can use the data. With IP-BLiS, gateways aren't needed because IP device traffic can be routed directly to standard servers on existing IP networks. Is it realistic to eventually replace gateways with routers?
The long term goal is for gateways to be replaced with software using generic IP capable hardware. In the short term, gateways will be needed to interact with the current deployed systems as the move to IP will take several years.
Building IoT deployments will generally involve both IT and OT departments. How is that going to work and what can each group gain from doing it?
Although specific responsibilities will vary by organization, IT will be responsible for the physical network and OT will work with the application layers. To be successful, both departments must work together to realize the benefit of a shared IP backbone.
Has IP-BLiS considered a collaborative and converged open-source software development approach to ease adoption?
IP-BLiS does not manage any open source projects. IP-BLiS is a market interest group. Some member alliances have or support open source projects addressing commonly used concepts. For example, OpenThread commissioning tools or OCF/Fairhair security tools may be used across multiple application layers.
How do the different protocols interoperate?
Gateways translate between applications and can be deployed as software or a cloud application. With IP it is possible for devices to implement multiple application layers, reducing component complexity.
Will there be interoperability between different wireless communication protocols?
IP-BLiS focuses on all IP-based wireless communication protocols, hence coexistence.
Will there be co-existence between KNX, BACnet and Zigbee?
Yes, for the IP-based options of KNX, BACnet and Zigbee.
What are the benefits of a standard IP-based installation?
IP-based applications coexist with other applications in the same network. Additional benefits include the reuse of IP-based infrastructure, the ease of cloud integration of different IP-based application layers, and limitless scalability. Devices on an IP-based network layer can be reached from anywhere in a building provided both sides have the necessary credentials (e.g. same security domain).
What demonstrable accomplishment will you provide to the BMS community one year from today?
A demonstrator project is under consideration. Details will follow.
Where does PoE fit into the IP control of commercial buildings?
PoE fits with the general connectivity ideas of IP-BLiS and delivers power at the same time. Wired products can benefit from PoE as a simpler installation method.
Which IoT connectivity is preferred, WiFi, BLE, Zigbee, Lora, NBIoT? Or is there an emerging IP standard permeating all of these?
Any IoT connectivity standard that supports IP is well suited. They already cover a wide range from low power to high data rate.
Will there be a common standard linking all protocols?
Yes, IP. The benefit of IP is that multiple carriers can be used without changing the application language. Certain industries may have a preference for a carrier technology which best accommodates their needs.
Will IP-BLiS allow the removal of gateways? If the application layer is not common, we can only upgrade from IPv4 to IPv6 in the case of BACnet?
Yes, hardware specific gateways. Software can create the gateway.
What network/PHY transports are considered in scope of IP-BLiS - Thread, BLE, WiFi, and Zigbee?
The IP-BLiS effort is IP based and PHY agnostic. The goal is to have IP communication between the currently siloed application domains. In short, if it is IP and suitable for the deployment, it can be used.
Why is IP needed to the end node?
There is a functionality and cost aspect to it.
- Each gateway needs to be updated to the latest changes of every other application.
- Each gateway needs to be kept up to date with security updates.
- Most importantly, every application ecosystem needs to trust all those gateways, because it lacks end-2-end encryption. Gateways require all security credentials to perform their translation task which breaks end-2-end encryption.