On the Integration of Computer-Controlled Building Systems

February: Control-System Integration<br/> A consulting engineer takes a look at some of the dangers inherent when integrating controls.

03/07/2001


Electronic systems are now the norm for the monitoring and control of the functions which are needed to operate a modern building. Fire and Life Safety systems collect inputs from smoke and heat detectors and fire-pull stations, and control fans for smoke exhausts, unlock egress doors, and sound alarm bells and lights. Security systems control card-accessed doors and monitor intrusion and glassbreak sensors, and direct CCTV cameras to the point of a breach of security, and instruct security guards as to the appropriate response. HVAC systems monitor inside and outside temperatures and sun-load and windchill, and control air and water flow and boiler and chiller startup and sequencing, and monitor operating conditions within their own mechanisms. Process Control systems operate and monitor the equipments and machinery which are used to manufacture the Company's products.

The central control element for all of these systems is a conventional computer, still known as a PC (Personal Computer) despite being the backbone of 90 percent of the world's industrial and commercial computer applications. The PC contains the data base which instructs its system on how to interpret inputs from sensors for smoke, intrusion, temperature, pressure, and what control actions to initiate in response: start a particular fan, sound an alarm, start a chiller, close a valve. The PC provides central monitoring of the status and condition of the system, and of alarms or emergencies or unusual conditions existing. The PC can automatically send alarms to the fire department, police, a central alarm monitoring station, or to a telephone call list of employees who are designated to deal with particular problems. The PC provides reports on the activity of the system and the functions under its control.

On the block-diagram level the systems all look alike,ither on or off: there is a fire or there is not, there is an intrusion or there is not. HVAC and process-control systems require the use of measured quantities, and their sensors provide actual temperatures, pressures, and flow rates. This requires different electronics in the field interface device (FID) and frequently different wiring to the sensors themselves.

The second difference is in the software which controls the operations of the PC; for example: Fire systems always sound the alarm when one of their sensors is activated; security systems sound an intrusion alarm only during the hours when the affected space is not normally occupied by working people; HVAC and process systems must compare the measured temperature against a particular value (the 'set point') before deciding to initiate an action.

Equally significant is the operator interface with the software. An urgent alarm is forcefully presented in all systems, but the routine presentation on the monitor screen is adapted to the needs of the persons who continually interact with the systems. Fire systems require no routine activity, Security guards need to lock and unlock doors and enable and disable alarms, HVAC operators need to adjust set points and open and close valves, and process engineers must control the mix of batches and the cutting of metal parts to fill customer orders.

At the really critical points there is considerably less commonality than first meets the eye.

The Integrated Building Management System

Recent literature abounds extolling the virtues of combining all of these functions onto a single computer-controlled system. The technical magazines, primarily in articles written by salespersons for companies selling building automation, state that integration 'is inevitable', 'is the holy grail for building designers and architects', etc. Certainly the technology exists and we engineers are therefore motivated, perhaps driven, to do it.

This is not the first time we have been around this barn. More than two decades ago a large engineering-manufacturing conglomerate which had as subsidiaries both a major elevator company and an HVAC company concluded that since it controlled the core of a building it could provide therein all of the principal building functions, including elevators, HVAC, communications, security, life safety, integrated office equipment such as word processing and fax. The technology existed even then, but after years of effort and expense they made no significant market penetration, primarily because no one company could compete across such a wide variety of technologies against those which specialized in the individual systems.

Those who advocate the integrated building system foresee the following kinds of features and design:

  • Shared wiring and communications networks from sensors.

  • Shared regional panels (FIDs).

  • Possible piggybacking onto the in-house LAN, systems could be accessed from many or any in-house terminals.

  • Common central computer annunciation and control.

  • Integrated software package providing common-mode handling of the separate systems.

  • Software makes decisions as to how the various systems interact with one another.

From an engineering perspective this is an elegant and satisfying concept which utilizes the ultimate in technology. From the standpoint of the building owner, whose needs should be paramount, it is a potential disaster.

Dangers of the Integrated System

One-Fail, All-Fail. This is the most obvious problem. If one shared FID fails we could lose all sensors on all systems in one area of the building. If the central PC fails (with or without the dreaded 'this program has performed an illegal operation and will be shut down') we are completely blinded and without control.

Unauthorized Penetration. Integration, especially including putting these systems onto the LAN, creates the virtual certainty that unauthorized persons can access functions and operations of the individual systems. Code requirements should protect the fire system, but security, in particular, must not be compromised. And connecting the HVAC and process-control systems over a widely-accessible LAN leaves the company open to sabotage and mischief.

Scarcity of Multidisciplinary Competence. The design and operation of a total security system is a profession in itself, as it is for each of the other systems, and there are precious few people who can intelligently design one kind, let alone an entire integrated system. We already see a deterioration in ease of operating the individual systems because they are being designed by computer programmers, not engineers or security people.

Cross-Disciplinary Ignorance. There are security system designers and installers, there are fire system designers and installers, there are HVAC system designers and installers. There are precious few who can handle a multi-disciplinary system.

Dangers of the Single Operator. Unified annunciation and control encourages management to believe that a single person at a single console can adequately cope with all of the building systems, but there are different sets of training and skills for the persons who must respond to security alarms, HVAC, process monitoring, and sometimes fire. It is difficult enough to provide an adequately-trained console operator for only one of the systems.

Too Many Cooks and Only One Pot. There will be contention for the use of the control console by the various system operators. Under emergency conditions this can quite literally cause a disaster.

The Myth of Economy

There are minimal cost savings to implementing the integrated system rather than the several individual systems. The central computer hardware is so cheap that they will soon be giving it away in order to sign you up for online services. (Even as in the 1960s, the era of the large central computer; we calculated that if the hardware were free the total system cost would drop by less than 10 percent.) The wiring from sensors to FIDs remains the same, and the FID cost is dependent upon the number of sensor points which are connected to it, and the panel-to-computer communications is a couple of pairs of telephone wire in either case. The software will become more complex and more expensive (and more prone to failure) because it must contain all of the features of the individual systems plus the capability to make all of the systems play well together within one PC.

There is minimal opportunity for labor savings. Security people and building-engineering people and process people are different persons and are in different places and should not be messing with each others' alarms and shunting and access privileges and set points. At best they might relieve one another for breaks, but that can be arranged in either case.

'Integrate' at the Top End

The design which best serves the owner's needs should be based upon interaction, not integration. Each of the individual systems should be designed and installed by the specialists in that business and should be controlled by and monitored at its own PC in its own location. Since the security system is the one which will be continuously attended, it should receive critical supervisory alarms from the other independent systems. 'Integrate' at the top-end, where the people are.

It is tempting to consider cross-linking all of the systems to one another at the top such that in event of failure of any individual system it may be monitored by the others. The problem with this is that the critical decisions and annunciations are created within the PCs, and if a PC fails the other systems must obtain information from the FID level. Ultimately all of the systems would be connected to all of the FIDs, creating a really complex mess. It is cheaper and simpler to protect against PC failure by adding a hot-redundant second PC.

This column was contributed by Dan M. Bowers, consulting engineer.





No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.