AutomatedBuildings.com Article - Control System Technologies

Control System Technologies

If the Open versus Closed argument indicates Open (as it will in most cases) then the choice is effectively between Lon and BACnet.

Jim Henry

National Marketing Manager,
Electromation, Australia

This is a series of articles on the delivery of BMCSs to our clients. This article will be a short look at what technologies to choose for a control system. For an overview of this series of articles read BAS or BS?

There are a lot of articles that look in depth at the exciting directions our industry is going. This article will take a step back and look at the basics of selecting the correct technology for a control system. What are the fundamental questions we are attempting to address for our clients?

Let's remember that it is not a given that a BMCS is necessary in every building. It may be that a good electronic system, such as the Siemens' Joker series, or Innotech, here in Australia, may suit a client's needs. Electronic controls can be serviced by an electrician or by the air conditioning service contractor. This will definitely reduce long-term costs.

However, there needs to be a consideration of the balance of all the long-term costs. If control logic is required a BMCS no longer costs any more to install than electronic controls. BMCS can add mixed-air controls, economy cycles, scheduling and other intelligent decision making to the mechanical system without increasing controller costs.

The real question is whether the increased cost of service (particularly if using a locked in firm) is worth more or less than the cost of the energy savings and the other benefits (such as remote dial in analysis, warning of impending equipment failure, etc) accrued from having a BMCS.

As long as the client has full access to the BMCS, it can be serviced for not much more cost than an electronic system. The next two articles, Specifications and Tendering, will address some of the practical considerations here. If the client's long term servicing costs are not protected at the time of system selection, then the long term servicing costs of a BMCS may be very high.

In theory, open should always be better than a proprietary protocol. This is based on the fact that there are now several systems entirely based on open protocols.

Open protocols offer only advantages for the client when compared to proprietary protocols. However, we must also consider delivery and the client's existing installed base. In reality, in a given market there may not be any reliable contractors offering open protocol.

If the proprietary protocol firms aren't given to pillaging (the proper technical term) their victims (clients) when they have them in a vulnerable position, and they are the best contractors in a given geographic area, then there may be no immediate and obvious reason to change contractors.

As well a client has to consider how much they already have invested in a proprietary system.

What a large client should avoid is delaying making the best decision, just because it is a hard decision. On that basis, companies would still be doing their accounting by hand, just because at any given moment it is more work today to change over for a benefit tomorrow.

If your existing controls contractor provides good service and treats you well you probably do not want to change. However, staff members and corporate direction change. Think through the implications if your control company brings in a brand new manager with a mandate to deliver another 5% gross margin back to corporate headquarters. (In North America, at least one of the controls majors gave this sort of direction to their branch offices during the market downturn of the 1980s.)

If the Open versus Closed argument indicates Open (as it will in most cases) then the choice is effectively between Lon and BACnet.

Honeywell, Siemens, Invensys, JCL, and TAC all promote Lon. These are the five largest control firms in the first world (leaving out Yamataki of Japan).

BACnet was driven through the auspices of ASHRAE to represent the client's interests in obtaining freedom from proprietary systems.

The author feels obliged to make it clear that he is a strong proponent of BACnet and has a very strong bias towards BACnet. But lets also be clear - the author is not promoting BACnet because his firm has a BACnet product; the author's company sells a BACnet product because the author firmly believes that BACnet is the one solution that best represents the long term interest of clients.

BACnet and Lon are very different beasties. There have been suggestions that these are competing technologies. In many ways this just isn't true.

Both systems are going to be around for the foreseeable future. This is not a VHS versus Beta scenario.

However, let's also be clear that there are limitations of each system. The only real limitation of BACnet is that is does not attempt to address programming or device configuration. Lon addresses these with LonMaker, which can configure multiple manufacturers' equipment.

Already one company has recognised the value in providing a gateway between Lon and BACnet. Tridium has developed a system that provides TCP/IP based communication and inhales both BACnet and Lon out of the box.

But this is not in the ballpark of the limitations of Lon as presented by the five majors. Many (sales-) people have tried to imply that BACnet and Lon are similar ways of achieving the same thing. With every one of the majors, though you may get Lon at the subnetwork level, you still have a completely proprietary front-end and proprietary primary panels handling routing and management level transfer of information. Effectively, they are opening up your system for interoperability at the device level, while still leaving you with a completely proprietary system at the management level.

BACnet provides interoperability between systems and the free exchange of complex data sets. Lon provides a solution for interoperability at the zone controller level.

If you want open systems, you should have BACnet handling all management level communications. BACnet easily scales down to the zone controller level. Lon is fine for zone control interoperability but is unsuited for system level interoperability.

Finally, let's discuss emerging technologies and consider if these should be implemented on our projects now. Those most under consideration are:

Enterprise Interfaces
Enterprise interfaces are software applications (Killer Aps) written to provide an interface between the client's operations and a system provider's standard applications.

Some examples with a BMCS would be to dump monthly chilled water consumption data to the client's tenant billing system, or to send filter alarm data directly to the maintenance department via the internal email system.

With BACnet we now have a standardised high-level interface to multiple manufacturers BMCS. The author wonders why more companies are not making a business writing enterprise interfaces using BACnet. Fidelio is probably the most common property management system utilised by hotels. With a standard BACnet Fidelio enterprise interface, any hotel or building using Fidelio software could be seamlessly connected to almost any BMCS. Immediately room occupancy, maintenance schedules, and alarms could be integrated with the BMCS.

These interfaces no longer need to be written on a manufacturer-by-manufacturer basis or worse, on a job-by-job basis. Any interface only needs to be written to BACnet as a standard application, and then that enterprise interface could be used by any manufacturer with a BACnet interface.

The larger your client's system is, the more likely it is that it makes sense to investigate available enterprise interfaces. Even with proprietary interfaces, it may make long term sense to absorb the initial cost of setting up the interface to automate the task of passing data between the BMCS and the tenant's billing, scheduling, or email systems.

Web Services
Web services are a specialised form of enterprise interface where applications are handled through Internet technologies.

There are two general types of web service for consideration. The first is using the web, as a transport mechanism, to move data around WANs and through complex network routers, be it the ubiquitous Internet or the client's own intranet. This has become standard and is offered by virtually every manufacturer. There is really no need for discussion. TCP/IP is the only transport protocol used to shuffle data around the web.

The second service is to use a web browser as the client's graphical interface. The first advantage of this is that it creates a single source of storing graphics, rather than storing static graphics in each machine accessing the system. The second is giving unfettered access to the BMCS to client staff, tenants, and customers. Every computer can be given the ability to change schedules, modify setpoints, and adjust lighting levels for little cost.

Web services are widely available from most BMCS providers. Many are still in their infancy, however. In most cases this is a feature that can be incorporated whenever the client wishes to add it, to provide greater functionality.

If it makes sense now, include it. If there is no need for it now, it can always be added later for the same cost (with the proviso the client is protected from predatory practises by the BMCS provider).

Integrated Building Services
This is the integration of the intelligent systems within commercial and institutional buildings. There are a myriad of advantages in having the air conditioning (HVAC), lighting, security, access control, fire protection, electrical, elevators, energy monitoring, and emergency power systems interact. Advantages include single seat operation, improved energy reduction strategies, and greater functionality.

Integrated systems can be achieved by having one manufacturer provide multiple systems and by having all the intelligent systems in a building use BACnet as a high level interface. This can be achieved using completely proprietary systems with BACnet gateways. This is not optimal, but is satisfactory. Optimal is going to Native BACnet as the standardised core of the installation. This will reduce integration costs.

Any size building will benefit from the integration of building services. The implementation of integration has been very slow because of procedural difficulties and integration costs. The advent of BACnet has removed the cost implication.

Practically however, the mechanical and electrical services are designed and tendered separately. It takes commitment by the Architect and the client to drive the process. On most projects integration collapses during construction, even if it is just within the mechanical services. Simply attempting to get the chiller talking to the BMCS can be a pain to coordinate.

Wireless Technologies
Most companies offer some sort of wireless sensors or interface.

Wireless sensors provide the advantage of eliminating the need for wiring from the controller to the sensor. At the present time the cost of wiring (to a local sensor) is about the same as the increased cost to provide a wireless sensor.

However, you will always need to wire power from the controller to the actuators and other power driven output devices. Look for the industry to continually move towards radio driven sensors and network communications. Remember though, there is no way to avoid wiring of power for controllers and actuated equipment.

There are certain applications, where today it makes sense to use wireless technologies, particularly sensors. Most manufacturers offer some form of wireless sensor, and these can solve some difficult retrofit problems, particularly in heritage buildings. In buildings with large footprints, like supermarkets, wireless sensors can provide lower cost installation while also offering more flexibility.

Events	Want Ads
Our Sponsors	Resources