Continuous digital workflows and unified information modeling are key enablers for efficient workflows, tools and solutions in modern building automation. How do new concepts and technical feasibility studies in the field assist in the transition to the digital era and building automation simplification?
Thomas Gamer ABB Corporate Research, Ladenburg, Germany, thomas.gamer@de.abb.com
Building automation – or smart building technology – is a fast-growing market. ABB has a strong position in building automation with, for example, products based on KNX [1], the world’s first open standard for the control of industrial, commercial or residential intelligent buildings. ABB is strong in building electrification, too, which allows the company to offer automation and power solutions in one, integrated package. In the future, other domains, such as grid interaction, local power generation and eMobility will become more tightly connected to the building and treat it as the central aggregator of digital information and solutions.
However, commercial buildings such as offices, hotels, or schools, which often have thousands of automation devices, typically do not display much commonality with respect to building automation functionality and electrification. This individuality entails complexity that makes the building costly to plan, engineer, construct, commission, operate and service. Multitechnology and multivendor integration, common in commercial buildings, further increases complexity→1,2.
Further, there are more roles involved over a building’s lifetime than just the building owner or occupant – eg, engineering consultants, system integrators, mechanical and electrical installers, and facility managers. These players are often ABB customers and they too must adapt to the increasing complexity, as well as deal with time pressure, inefficient tooling, customer demands for open ecosystems, or new regulatory demands.
These issues raise the question: What workflows, tools and technologies can be used in building automation to meet all these challenges and support more integrated, time-efficient solutions and open interfaces?
Pains and gains
To answer this question, ABB carried out a research project that focused on the early lifetime phases of the commercial building automation, ie, planning, engineering and commissioning→3. This scope addresses the abovementioned challenges and, therefore, many of ABB’s customers’ pains. Many aspects of the work are applicable to smart homes, too.
Key customer demands in this phase of the building automation lifetime are:
• Follow the trend of function-based specification
• Support multitechnology and multivendor projects
• Ensure continuity of workflows from design to operations without information loss or need for manual work
• Move toward open but functionally integrated ecosystems
Function-based specification means that during the planning phase, building automation functionality is specified independently of technology, vendors, devices, etc. Such specification is often based on, for example, the VDI 3813 standard [2] for room automation functions.
Most building owners, and, therefore, engineering consultants and integrators, want to combine best-in-class solutions to achieve their intended automation functionality. Therefore, different technologies might be chosen, eg, KNX for room automation, BACnet for central heating and ventilation, and ZigBee for retrofit or installation locations that might be costly to wire. On top of all this variation, different vendors might be chosen for different device types.
The continuity of workflows has several aspects:
• Currently, multiple tools are used from planning through to operations. These tools often do not have well-defined interfaces.
• Handover between roles is often done via paper or pdf documents. Such a transfer cannot be processed automatically.
• Usability is sometimes an issue, especially if multiple technologies and devices from multiple vendors must be integrated – most often across multiple tools.
An open ecosystem allows continuity of workflows because it guarantees interoperability while being flexible and extensible enough for new technologies or technology alliances.
The customer benefits of the ABB proposed solution that emerged from the research project are:
• Functional specifications based on standards
• Increased time-efficiency by automating as many steps as possible
• A continuous tool chain and unified information model to avoid error-prone manual work
• A device package concept offering a standardized way to integrate devices with different technologies and vendors
• A modular software platform with well-defined interfaces to integrate with existing tools, eg, ETS for KNX or cloud services
Overall picture of the proposed solution
The key element for all lifetime phases described below is ABB’s unified information model (UIM). UIM is a domain model that describes and structures all information required for the lifetime of the building automation system. In addition, it provides various entry points and implementation methods. Entry points are, for instance, building structure, automation functions or installed devices. For the prototype, ABB decided to implement a single instance of the UIM for all lifetime phases with OPC UA (OPC Unified Architecture) [3], while providing additional interfaces.
First, the actual workflow steps from building design to operations, which were common across domains and geographic regions, were clearly defined→4. During the planning phase, common tasks are to define the building structure, automation functionality and, finally, create a tender document. Planning is entirely technology-and vendor-agnostic, as actual devices are not yet considered.
During the engineering phase, the main tasks are to select actual building automation devices that fulfill the given specification and perform a first high-level configuration, eg, dimming levels for light switches or default temperature setpoints for heating actuators. Depending on region, project and customer, the system integrator can choose devices from his own catalog of preferred vendors or get a list of already installed devices from mechanical and electrical installers. This means that the proposed solution must cope with differing implementations of the overall workflow. As actual devices are involved in this step, multitechnology, multivendor integration concepts are required. The main element of the ABB solution in this step is the new device package concept, which enables the mapping from actual devices and their technological details to the functional abstraction of the planning phase in a standardized way.
During commissioning, a common task is to perform detailed configuration of the technology-specific parameters as well as the discovery of, and download to, the automation devices. Some technologies have mandatory commissioning tools, such as KNX with its ETS tool. In the ABB solution, existing tools are directly integrated into the workflow. With multitechnology systems, there is also the need for a device – the “automation hub” – that can understand the different technology segments, translate between them and potentially also execute advanced functionality. The automation hub is part of the operations phase but might also be used to commission technologies like ZigBee, which do not require a separate commissioning tool.
Key elements of the proposed solution
Key elements of the solution are tool prototypes, software platforms, technological artifacts such as the UIM and device packages, as well as existing tools like ETS.
Planning and engineering tool
This tool prototype→5 is based on HTML5 and can be packaged as a Web tool or standalone desktop version. The tool covers most aspects of planning, engineering and commissioning. It allows users to create a building structure and functional specification in a time-efficient way, eg, by offering a library of VDI 3813 function blocks, custom macros, search and filter functions, automatic validation and BIM (building information modeling) import of the building structure. A tender document can be created, or the project can be saved and sent to a system integrator. For the engineering phase, devices can be selected from a catalog by drag-and-drop. Basic channels and semantic parameters can be configured. Time-efficiency and usability are ensured by device search and filter (eg, for technology or vendor), preselection of valid devices for specific function blocks, custom device catalog import, tool tips or template definition. Finally, file export to ETS is offered as well as discovery of, and download into, ZigBee devices.
Device package
To support or automate the selection of devices for a functional specification, this artifact describes a device’s functionality and a mapping of technology-specific to semantic parameters. The ABB concept offers a standardized way, based on XML schemas, to create such device descriptions. Moreover, one can reuse and integrate existing information such as KNXprod files, which have simply to be extended with the semantic mapping information. The approach is applicable to various technologies.
Configuration generator
This artifact is part of the planning and engineering tool and fully automates the task of technology-specific configuration, ie, rules and heuristics are implemented to autogenerate a complete, valid and working configuration, eg, for the KNX part of a building automation system.
ETS importer app
This tool prototype takes the KNX-specific export of the planning and engineering tool created by the configuration generator and imports and translates all information into the data model of the ETS commissioning tool, which is mandatory for KNX devices. The design decision is to reuse available tools but also to allow a user to adapt the autogenerated configuration before download if needed.
UIM
This artifact provides a structural model of all required information and ensures understandability and portability of information by its well-defined structure, entry points and semantics. The UIM uses standards like the OPC UA DI (device integration) model [4] as a basis and defines a small core model with extension points for semantics as well as technologies on top→6. Thereby, it is modular and maintainable while still open and extensible; and it supports usage of multiple semantics and technologies in parallel. ABB implemented the UIM into an OPC UA server and is using it over the entire lifetime of a building.
Automation hub
This tool prototype is a modular and flexible software platform with the UIM as its core module. The automation hub wraps the OPC UA server with various interfaces such as REST or oBIX for easy integration, eg, into cloud services. It can be packaged with additional modules for advanced services as a full platform for the operations phase and can be executed, for example, on a Raspberry Pi Model B+. Alternatively, it can be packaged as a single module together with the planning and engineering tool and then transparently store and provide all required information without the user knowing it is there.
Feasibility study and demonstrator racks
All the concepts and key elements mentioned have been implemented and integrated into a demonstrator rack to validate feasibility and allow discussion with project stakeholders. The rack represents a meeting room in an office building that is equipped with advanced automation functionality such as constant light control, heating and ventilation, presence detection, and window sensors. The installed devices are from multiple vendors and use KNX (lighting, user interface, presence detection), BACnet (heating and ventilation control, user interface), and ZigBee (window sensor) as different technologies to ensure relevance and heterogeneity. The entire planning and engineering was performed with the prototypes described above. For KNX, the automatic configuration was used. For BACnet and ZigBee, the discovery and download feature of ABB’s tool prototype was used, which means that only the standard profiles and objects of those technologies were used. It should be mentioned that the prototypes still apply some simplifications and are not fully-featured but focus on most challenging key features.
First customer demonstration and feedback sessions confirm that the proposed concepts and feasibility studies address actual customer challenges and that customers see valuable benefits in these concepts for their daily work as well for mastering the transition into the era of digitalization. Future research work will address topics not in the present project scope, such as integration with electrification, model life cycle management or addition of features required by specific technologies, market segments, or user roles.
Acknowledgments
This article would not have been possible without the ideas, work, and dedication of the entire project team and project stakeholders. Special thanks to Roland Braun, Florian Kantz, Somayeh Malakuti, Johannes Schmitt, Katharina Stark, Michael Vach, Retus Cathomen, Jens Czudai, Dirk John and Christian Lehnert.
References
[1] KNX Association. Available: http://www.knx.org
[2] VDI, “VDI 3813: Building automation and control systems (BACS), Room control,” May 2011.
[3] IEC, “IEC TR 62541-1 OPC unified architecture - Part 1: Overview and concepts,” Oct 2016.
[4] IEC, “IEC TR 62541-100 OPC unified architecture - Part 100: Device Interface,” March 2015.
