AutomatedBuildings.com Invitation - CSI Roundtable May 19 in Santa Clara California

Please plan on attending and sharing your thoughts on this Convergence View of Specifications roundtable

What is CSI? The Construction Specification Institute provides Standards & Formats, Professional Development and Certification. For more information, visit www.csinet.org The recognized industry standard for more than 40 years, MasterFormat 2004 Edition replaces MasterFormat 1995, expanding the well-known "16 Divisions" to 50 Divisions of construction information.

As the organization who have for decades defined specification formats for buildings, CSI is now looking at technologies such as BIM and the effects of connectivity and IT to the future of building construction and operations. In cooperation with key members of CSI, this Roundtable will discuss technology and specification issues related to convergence of building systems and IT.

Status of CSI Standards, BIM & MasterFormat
9:00 am - 10:00 pm
From CAD to information standards, members of CSI will outline initiatives that affect the construction and operation of buildings. Key to these standards is BIM (Building Information Model) that will be an important way for all stakeholders involved with buildings to describe the components that make up buildings.
Convergence View of Specifications
10:00 am - 11:00am
With convergence of buildings and IT, comes new possibilities of change for the good, specially in the way that owners think about buildings, design and specify their construction. From design-build, to new forms of performance and results based specifications commonly used in the IT realm, this session will review how these methodologies can be used in specifying buildings and building systems.
Collaboration Discussions with CSI
11:00 am - 12:00 pm
This session is designed to provide an open forum discussion between those from CSI and convergence minded stakeholders at BuilConn. The session will also outline actionable future steps in collaboration between these two groups.

I have a strong position against continuing down the path we are on in so far as the specification process is concerned. It is a widely held belief among specifiers that if we could just make the project specs more precise many of the problems we experience with the end results will go away. I find this position most uncompelling. Instead, my view is that the process as currently applied ignores the really critical issues in specifying and selection systems and equipment, and that is why these systems so often under perform. While detailed specifications for individual components are important at some level, that level is most certainly not the project level at which I would assume such a seminar would be directed. Here we need "performance' grade specifications.

Certainly it is true that the industry cannot succeed with trying to implement such an important structural change for just in one element of an overall system design, but on the other hand we cannot simply continue down this path of improperly specifying systems and equipment either. For these reasons, I argue that the current method of specifying equipment needs to be scrapped and redeveloped with a bold new approach that recognizes the project level requirements and divides equipment according to actual functional boundaries.

That's fine. You can quote me, but in your discussions you ought to bring up the fact that the traditional way of having a mechanical subcontractor and controls as a subcontractor to the mechanical really limits the owner's input and the ability of the controls contractor to provide whole building integration. It's not unusual for the mechanical subcontractor to actually select the control system and hire the controls sub-subcontractor. When that happens, selection is typically either on a least-cost bid basis or it's determined by an existing working relationship between the mechanical and the controls contractors. In either case, the owner's input is limited and the controls are focused on the mechanical system, not on building integration.

In general, we control system vendors are not really driving the train on this issue. We manufacture a product which is very flexible and can be used for whole building integration, particularly with the use of standard protocols like BACnet and BACnet Web Services to integrate with other building systems, but in practice our system is most often installed by a controls contractor who's a subcontractor to the mechanical contractor who's a subcontractor to the prime so the focus is on mechanical system controls. Controls engineers I've met from large AE firms tell me there's not enough interest in controls at that level to even allow them to specialize in control systems, they wind up doing primarily mechanical design with a little controls work added in at the end. I suspect lighting and security controls are designed similarly. Tom Harman is absolutely correct when he says that changing this system will require a completely new approach to specifications. I've seen projects where the building has been designed as an integrated whole and I believe this trend is increasing, particularly with the emphasis on LEED and sustainable buildings, but I would not yet say that most buildings are designed in that manner. Building owners need to take the lead in making this change happen and they need to be willing to spend the time and money up front that is required to get an integrated design vs a "cookie cutter" assembly of stand-alone systems. It's the old first-cost vs life-cycle cost debate. Everyone pays lip service to life-cycle costs, but when they look at the budget many will issue a least cost bid contract.

[an error occurred while processing this directive] Ron Poskevich, General Manager LUMISYS - Panelist

Lighting control is a small piece of the overall building, but it is a key component of DR and other energy initiatives. We have had success changing the specification to place lighting control into the scope of work of the control contractor. This eliminates any integration uncertainty and associated premiums. In addition to these tremendous benefits it is also driving some innovative sequences with lighting, HVAC, and security/access control. LEED and other programs are making this easier, but we are still early in the adoption process.

Toby Considine Panelist oBIX (Open Building Information Xchange) - Panelist
Toby writes You left out a big piece for the CSI The Facility Master System Integrator (FMSI) as a standard section….

While we are proponents of controls specifications that are generally performance based, there are portions of any design that needs to be highly prescriptive. Open/standard communications protocols is probably the most important example of where a specification should contain explicit, prescriptive requirements. This is especially true in projects where integration with an existing BAS is being undertaken. Specifications not only need be detailed about the type of protocols and their option for each portion of the system, but should also cover the proper protocol conformance testing and certification to which the controls must conform.

Further, today’s building automation systems involve the integration of controls elements spread throughout many specification sections (i.e., controls provided with mechanical equipment and/or systems in other divisions such as lighting control). This trend has shown that, for each “element” in the system, we need to very carefully and explicitly define:

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

Events	Want Ads
Our Sponsors	Resources