BTL Mark: Resolve interoperability issues & increase buyer confidence
CSI Roundtable May 19 in Santa Clara California
|Ken Sinclair Track Leader:|
I am the CSI Roundtable Track Leader: May 19, 2008 @ http://www.builconn.com/2008/na/agenda/track.asp?qsTID=199
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.
What are some of the sides to the round table?
Tom Hartman,The Hartman Company - Panelist
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.
Be sure to read Tom's article Creating a Sustainable Building Industry Future
Steve Tom of Automated Logic - Unable to attend,
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.
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….
In a two part column from our online magazine More on the Challenge of Writing the Controls Specs…. http://automatedbuildings.com/news/may08/columns/080424113924ehrlich.htm
Paul Ehrlich & Ira Goldschmidt of Building Intelligence Group Unable to attend write:
Be prescriptive for key elements
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:
The communications protocol to be used (which must be specified in both the building automation section and the other mechanical/electrical equipment sections).
How the elements are connected (i.e., what type of wiring and/or LAN technology is to be used). In some cases an owner’s Ethernet/IP infrastructure can be used, but this oftentimes carries with it constraints concerning proper use of the infrastructure that should be specified.
What data is to be shared (and whether the data needs to be controlled or, more technically, writeable by the building automation system).
How the joint sequence of operations are to be divided between the building automation system and mechanical/electrical equipment. For example, what are the chiller controls responsible for vs. the building automation system?
Finally, detail needs to be provided about the division of responsibilities between the various contractors/suppliers involved in providing and making these controls elements work together as a system (sorry, but the temperature controls contractor can’t possibly be responsible for everything involved with integrating mechanical equipment-mounted controls).
Please join us it is bound to be a very interesting roundtable
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]