AutomatedBuildings.com Article - Restructuring for the Componentization Era

Restructuring is definitely happening, but is it happening fast enough? And when it comes to building automation, what shape will the future take? Armed with these questions and others, the author queries leaders in the industry about the ongoing building automation challenges and the latest trends pursuing solutions. In some cases, new ideas and methods may rise above some familiar ways and means.

My February 2001 article in Engineering Systems “The Componentization Era Is Here” talked about the line between equipment and controls blurring and an ushering in of a rethinking of what building HVAC systems do. Feedback in the May 2001 issue “Letters to the Editor” pointed out that much industry restructuring was necessary to move toward the componentization concepts. John Moyles P.E. of Kling Lindquist in Philadelphia wrote:

a) to specify generally available Human Machine Interface (HMI) software, such as those available for SCADA systems; and

b) to require that the control systems vendor use a Windows operating system that will send data to a central server running the HMI. The server will provide the graphics and will relate the received data points to the graphic.

I agree conceptually, but my bias would be to force the (HMI) software to web based standards, which may or may not include SCADA. The concept we agree on is that the owner must take a more active role in the integration of large automation projects into his enterprise. The old bid and spec approach does not work well in the new environment where the enterprise interface has become as important as the end control.

In my August ES Building Automation column Leave Yourself Room For Progress I talked about the problems specifying when building automation evolves so rapidly. I pointed out the advantages of the Request For Proposal (RFP) approach and below is a brief summary of the major concepts discussed.

Having set the table on how this conversation began, let's see how it evolves with the help of several leaders in the controls industry.

[an error occurred while processing this directive]From an interview with Gerry Hull, President/CEO of Automated Logic Corporation and Steve Tom the Director of Technical Information:

Sinclair - The traditional bid and spec approach is giving way to request for proposal and or design build. What are the pros and cons?

Hull - Tom: The pros are that the new procurement methods give you a much better way to take advantage of new ideas and new technologies. The cons are that they're much tougher to evaluate and manage, and it's even more important that the contract goes to a reputable firm that will work with you to overcome thousands of problems and unforeseen events which occur during any major building project.

There was never a spec written that could force a dishonest contractor to become honest, but at least they "reined in" the ones who were leaning in that direction and gave you a big club to hold over them. The disadvantage was that they also reined in the honest contractors, and forced them to "design down" to the lowest cost system that would meet the technical provisions in your spec.

If a new product was available that was better than what you specified, he couldn't afford to base his price on it because it might cost him the contract if it was more expensive, or you might reject it and force him to use the specified item if it was cheaper. The RFP and Design/Build approaches allow (force?) the buyer and the contractor to become partners, working together instead of sparring in an adversarial role. Like any partnership, you just need to be careful with whom you partner.

My September ES Building Automation column talks about Industry Restructuring and quotes from interviews with industry leaders Hartman and Zaban. My conclusion is that restructuring is just that, a complete reconstruction of the existing control procurement process and methods of doing business. I find that while many players in our industry feel that only minor changes are occurring, both Toms and Hull point to major restructuring. Restructuring that will change who we are and whom we work for. Equipment manufacturers are not willing to adapt new technologies unless the purchasers of their products drag them kicking and screaming into radical evolution.

The capability of today’s building automation systems far exceeds the present understandings of the existing implementers.

Communication Protocols are a large part of the present industry restructuring. In the same interview with Automated Logic I asked the question:

[an error occurred while processing this directive]Sinclair - How would you recommend that owners handle protocol standards and IT convergence to allow themselves the option of changing control contractors in the future?

Hull - Tom: At the IT level, buy systems that fully embrace Web standards throughout. It is the only way to follow the Web wave of new products and services that will be flowing for years to come. At the HVAC protocol level, buy BACnet. It is the only protocol out there with the robustness and HVAC system features that can handle the job. There are other protocols but every one we have seen is full of too many "gotchas", limitations, and can only be implemented with proprietary fixes and "workarounds". Some look great in the beginning, but in the end they are skilled labor intensive.

The same question was presented to Kevin Lynch, Executive Director of the LONMARK® Interoperability Association

Lynch: Clearly the right path is to embrace the Open Systems model endorsed by many of the companies in the LonMark(r) Interoperability Association and Echelon's Open Systems Alliance program. Both of these initiatives are all about choosing best of breed products, services, contractors and integrators. The building industry is moving rapidly to open systems with open choices, get over it or get out.

In an interview with Rehan Kamal, IT Strategist at Computrols he approaches interoperability problems with full web solution.

Sinclair - What about interoperability? Can Web-accessibility be provided by a company that is not the BAS contractor/manufacturer?

Kamal: .Web Server (which "talk" TCP/IP) product is just that--a Web Server would be a window into a BAS. Other vendors in a building may use this type of access to the BAS system. However, this type of access will generally be limited to humans, not other BAS controllers or computers. Hence the BAS software would integrate equipment from multiple manufacturers, independent of the Web Product. This in turn can be placed on the Web. So, although the Web product can be used to integrate multiple vendors, this capability would have nothing to do with the Internet access itself.

Another avenue would be, TCP/IP internet-ready controllers which can be made to have completely open Internet connectivity right down to the controller level. Thus WWW access would be available at the controller level for human-to-controller access. But more importantly, XML and other standards can be used for truly open, third party, controller-to-controller connectivity. I fully anticipate the industry to move in this direction.

Kamal: The building automation industry is going the way of Internet Appliances. That is ... TCP/IP connection to every single device in the building--not just the front end computers. Internet connectivity from PC to PC reached maturity in the late 90's. Now, there is a huge amount of R&D effort and money going into Internet connectivity for appliances in the home and office. Standards like Blue Tooth, Universal Plug and Play, Jini, HomePNA, and others will drive Internet connectivity in the coming years. Internet appliance technology will reach wide acceptance and become common place by 2005. This is not just in the building automation industry, but in every industry that can use that level of connectivity.

[an error occurred while processing this directive]Rand Arnold is founder and President of ControlShop, as well as a principal of Objective Automation, a consulting firm focused on the delivery of integrated automation systems based on open standards. He provided the following information in an interview:

Sinclair - Numerous companies now characterize their systems as 'open'. What do they mean?

Arnold: Openness in a product or system is fundamentally a measure of the level of standardization in the non-application specific elements. The degree of openness is effectively proportional to the degree of standardization. Standards are the foundation upon which openness is built. To achieve any degree of 'openness', certain standards must be established and agreed to.

While the building automation industry certainly has not led the charge in establishing protocol/communication standards, it is slowly recognizing the value. The two standards receiving the most press in our industry are LonWorks and BACnet. Remember, however, that a variety of other standards are also playing a critical role, like IEEE 802.11(Ethernet), the IP protocol suite, and other Internet related standards like XML.

Sinclair - Can you provide a checklist for designing an open control system?

Arnold: I can certainly point out a few key ingredients. For starters, address wiring. The base for a building wide-open control system is intelligent wiring. Starting with wiring grants the integrator and end-user the ability to quickly and easily install the system as well as make additions and revisions in the future.

Almost as importantly, eliminating the physical barriers between systems encourages engineers and owners to create holistic building control. After the wire is in, examine how the devices will communicate. It is crucial that the devices installed on the common infrastructure share information without effort. So the products must adhere to a common communication guideline. As previously determined, this means the devices must use standard communication variables. This is the purpose of standards like LonTalk and BACnet.

After communication, consider the effort required for configuration. To make integration easy, a device must not only support standard communication, it must support a standard interface for configuration. Look for guidelines that provide for the physical layer requirements of devices as well as the common data types, configuration capabilities, and installation methodologies. While it's adequate for product manufacturers' to simply document the configuration interface for their device, it's obviously better if they encapsulate the knowledge into program that can be run.

Once these aspects are nailed down, its time to think about how the system will be tied together. Standard network management services provide the necessary network services and published interfaces for an open infrastructure. These services allow multiple tools from multiple vendors to coexist on the network. More importantly, it allows the various tools to share the network data. Integration is possible without standardize network management, but it is complex and costly.

[an error occurred while processing this directive] A system in today's market is not complete if it does not provide Internet access. The Internet Protocol suite is the standard on which the Internet is built. An open control system must provide for encapsulation of the control system messages or packets into TCP/IP datagrams. Messages can then be passed around the world without translation into foreign protocols. The cost of transmission is minimal and the ability to leverage existing infrastructure practically limitless.

Finally, limit gateways to the extent possible. At any point in the system where the messages between devices is mapped from one communication protocol to another, the control network effectively ends. The 'mapping' of messages from one protocol to another is accomplished via a gateway. Gateways should only be used for interfacing to legacy systems or in situations where standards are unavailable.

Every one knows that gateways have been a staple of the commercial control industry for the last 10 years. They often provide a necessary function. They are, however, bottlenecks in the flow of system data and are inherently performance limiting. Performing the functions of a gateway requires processing power, which translates into higher cost. Gateways also require someone to indicate what should be mapped to what which consumes engineering efforts. Finally, gateways are difficult to maintain. Any change in system parameters has to be addressed at the gateway as well. As a gateway is a transition from one communication protocol to another, it almost always is accompanied by a change in network management schemes. Different management schemes mean different tools are required for either side of the gateway.

Tridium and others are working on a new Java standard to take advantage of the power of the Internet

Baja (Building Automation Java Architecture) is a standards effort with the mission of creating an open, Java platform for the building automation market. Baja is a suite of component software applications designed from day one to take advantage of the power of the Internet, support true plug-and-play and allow for complete multi-vendor interoperability.

By using Java APIs and XML schemas, Baja allows developers to converge multi-vendor device protocols and communication standards with Internet technologies into a single universal standard and adapt them into an open, interoperable environment. The result is a solution that unlocks the potential of smart devices and the Internet in ways previously unimaginable, while providing significantly lower automation and information infrastructure costs.

[an error occurred while processing this directive]The expert group shepherding Baja through the standards process consists of many of the major players in the automation industry. They include:

Major restructuring of our industry is happening. Web-wise solutions with full integration with the "Componentization Era" are being fashioned slowly into powerful enterprise controls systems. Much work and restructuring is required to make the concepts outlined in the Componentization Era article real. Enterprise-enabled controls will address all building management issues such as energy efficiency, client comfort interface, and equipment self-diagnostics as well as client comfort, world wide operations, national utility control and more. It is now possible to all of that, but we must work together to restructure our present infrastructure to make it happen. The pressure is on, because if our industry does not do it, another industry will.

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

Events	Want Ads
Our Sponsors	Resources