For more than a decade, interoperability has been the focus of building automation systems. Building systems that adhere to a set of standards enable independent systems to interact with one another. This increases building management capabilities, improves operating efficiency and flexibility, and reduces installation and expansion costs.
Standards promoted by BACnet and LonMark have demonstrated the many benefits of interoperability. More and more devices are being marketed by an ever-expanding network of system and component manufacturers that conform to one of the standards.
But the move toward interoperability has produced other efforts that, while less well known than BACnet or LonMark, nevertheless promise significant benefits. Interoperability has the potential of improving practically every aspect of facility management, from construction through day-to-day operations.
It is hardly news that the building industry has made use of information technology to improve capabilities and reduce costs. Computers develop drawings, manage data, model operations, track expenses and run systems. But little has been done to integrate those systems into a single, interoperable whole.
These systems are best described as islands of information. Each phase of the building project, from planning through operation, develops its own independent data that cannot be easily shared with other phases. Even within each phase, not all participants have access to all information.
The problem is obvious. What happens during the planning phase affects construction. And what happens during both planning and construction can have an impact on operations. But without consistent access to and exchange of information, data becomes lost, and operations suffer.
Interoperability can help to remove the barriers and change islands of information to a seamlessly integrated whole.
A range of industry organizations is currently working to change the way the entire building industry operates. One example is the International Alliance for Interoperability. In 1994, the Alliance for Interoperability, later renamed the International Alliance for Interoperability (IAI), was formed to define, publish and promote a specification named the Industry Foundation Classes (IFCs). The IFC specifications allow users to assemble and share project information in a way that is independent of the operating system, software package and location of the information.
It’s easy to see why this approach to interoperability is important. CAD packages, system design packages, project management packages, scheduling packages, energy-use simulation packages, project takeoff packages — all operate as independent software applications, unable to communicate or share information. Each package generates a large volume of data that is shared inconsistently among project members. Data generated by one package must often be interpreted and manually transferred to another, resulting in duplication, omissions and errors. While some interfaces allow translation of information from one software package to another, they are expensive and software-specific.
The goal of the IFC effort is to create an environment in which multiple applications can exchange information directly with any compliant software package. Consider drawings developed in a CAD program that adhered to the IFC specifications. Simulation software could access that data to evaluate HVAC system sizing or energy performance. Similarly, takeoff software could use the drawings directly for cost estimating. Project management software could access all other packages to make it easier for facility executives to manage the process from start to finish.
Sharing data, eliminating duplication, reducing errors and scheduling project phases more quickly could save up to 30 percent of the total project cost. Additional savings would come later because all project information would be available to those who manage the facility once construction has been completed.
Eventually, designers will be able to interact with codes that govern construction to ensure that the design complies with all applicable building codes.
The first phase of the IFCs, the project model, was released approximately one year ago. The IAI interoperability project includes members of the architectural, engineering, construction and facility management industries, software vendors, research institutes and professional organizations.
Building security systems, like building automation systems, evolved from simple hard-wired devices to complex computerized networks. And as was the case with building automation systems, each vendor developed its own proprietary system that was unable to communicate or share information with other security systems. In 2003, a cross-industry group headed by Computer Associates International launched an effort to develop standards for integrating physical security and information technology security. Since then, the effort has been taken over by Industry Standards and Technology Organization (ISTO), an organization formed by the Institute for Electrical and Electronics Engineers (IEEE). The Open Security Exchange is the name for the vendor-neutral, interoperability specifications being developed by the group.
While facility organizations have made significant investments in both physical and IT security, many of those efforts have remained fragmented. Physical security is, in most cases, separated from IT security, often following a totally separate chain of command. The result has been that, despite significant investments made by organizations, large-scale breaches of security have occurred, with millions of dollars in damage.
For example, two independent security systems found in nearly every organization are physical access control to the facility and password access control to computer systems. No sharing of data takes place between the two systems, so it is impossible for the computer system to deny access to someone when the right password is used even though the user is not in the building. This lack of data sharing makes it relatively easy to access data through stolen passwords.
Development of an integrated security program has been hindered by the widespread use of proprietary technology by those systems. As a result, significant holes exist in the security infrastructures that are difficult to address with existing hardware, software and management policies.
By developing a vendor-neutral interoperability specification, Open Security Exchange will enable a more effective exchange of security data throughout the organization, reducing both threats and operating costs. The first phase of that specification addresses interoperability between physical- and cyber-security technologies.
OLE for Process Control (OPC) is an international software standard developed to share plant and process control data with business applications. It is an open standard that promotes interoperability through a series of standard specifications designed to allow the transfer of information throughout the enterprise regardless of the vendor. It is based on principles adapted from Microsoft Windows integrations standards.
OPC is controlled by the OPC Foundation, an organization of more than 300 members around the world that is promoting interoperability in the industrial and manufacturing sectors. Its members include most of the major providers of control systems, instrumentation and process control systems, along with Microsoft itself.
As with building automation and security systems, the use of proprietary systems limited the ability to access and act upon data within separate systems. Similarly, once a company had purchased a particular vendor’s system, it essentially became locked into that vendor for the life of the system.
The OPC Foundation is working to eliminate those barriers through a series of standards. The first defines a standard set of objects, interfaces and methods for use in process control and manufacturing automation applications. Six other standards are either complete or under development.
Because these are open standards and based on the general computing market, OPC will support the needs of industry. Users will be able to mix and match hardware and software components without becoming chained to a single vendor. Vendor costs will be reduced as they will not have to develop individual drivers for each of their hardware and software applications.
Of course, building automation system vendors continue to work on interoperability. While the initial goal was to make the systems vendor-independent and able to communicate with other systems, today system designers are looking beyond the traditional building functions to the enterprise.
Building automation systems need not stand independent of other enterprise operations. Instead, they can be viewed as active components in the management process, providing information needed to make day-to-day management decisions. This increases the need to share information between those systems and between those systems and other IT systems in the organization.
XML or eXtensible Markup Language is a software standard widely used in the IT community for storing, publishing and exchanging information. With XML, users can transmit any kind of information over an existing IT infrastructure, such as the World Wide Web or a company’s intranet, no matter what operating protocol is being used by the system requesting the data or the one providing the data. With XML, users can share data across different software applications and operating systems easily without having to update or replace those applications.
Initially developed in 1998 by the World Wide Web Consortium, XML has won widespread acceptance in the IT arena. XML promises to do for data exchange what HTML has done for data display on Web pages. HTML standardized how different information should look across multiple platforms. XML provides the needed structure for organizing and exchanging data.
For facility executives, a key benefit of XML is the access it provides to a wide range of information from various building systems: building automation, maintenance management, financial management and asset management. The goal for building systems that use XML is seamless communications with other IT systems, such as accounting and asset management.
James Piper, PhD, PE, is a writer and consultant who has more than 25 years of experience in facilities management. He is a contributing editor to Building Operating Management.
Lighting protocol brings efficiency, flexibility
While building controls manufacturers have been creating standard protocols to allow facility components from different manufacturers to communicate, manufacturers of lighting system components have been doing the same.
Lamp, ballast and lighting control manufacturers have been developing and implementing a protocol known as the Digital Addressable Lighting Interface (DALI). Much like BACnet, LonMark and other open protocols do for HVAC, security and other facility systems, DALI-compliant lighting systems allow facility executives to initiate sophisticated control and monitoring schemes.
Products built to DALI specifications behave and communicate in ways outlined in set standards, allowing ballasts made by one manufacturer to communicate with controls made by another and lamps made by yet another. Although initially used exclusively in architectural lighting and daylight harvesting schemes, the standard is being used increasingly to deploy dimming strategies across fluorescent lighting systems in entire facilities.
What makes DALI products more effective than components used in traditional dimming control setups is their ability to communicate with a central computer network. Ballasts not only respond to instructions to set light output at certain levels, they also send information back to a central computer so that operators of the system know the output of the lights, preset light levels and the condition of the ballast.
The system also allows control over individual light fixtures, as opposed to having a single dimmer control lights in an entire room, and can interact with daylight harvesting, occupancy and other sensors.
Limitations to DALI include the inability to interact directly with building management systems. The protocol was written only to govern lighting components. Integrating a DALI system with a facility’s automation systems requires the use of gateways. One other limitation is that a DALI network can only contain 64 points. Controlling additional points requires the installation of a second network. — Mike Lobash, executive editor |
