Open Systems Standards Pick-a-BUS: Open Systems Standard Direct Digital Control using Object-Orientated Code for Building Automation, commercial & home automation

Paul D.J. Mason, C.E.O.  BWP plc Contributing Editor

This is the fifth of 9 articles where we are introducing the cost benefit for interoperability and that gained from the procurement technique achievable with open systems and choice.  This article sets out some of my opinions, a collection of web-based technical data and then a current market summary opinion.

July's article LonMark International and the LonMark System
June's article More Intelligent Building and save money, VBHQ part 2
May's article Intelligent Intelligent Building, VBHQ Part 1
April's introductory article Cost Comparison Model Open vs Proprietary

my Basis of Argument:

• end-users or development promoters want lower cost and value, no lock-in and future proof, openness and choice

as this contributing editor is a building services consultant these things are known from experience to be true

• BUS technology is observed to be sector based by many commentators

this is clearly a generally held belief, industrial or automotive BUS have not crossed over to construction and probably will not crossover “Web-services” have crossed over and will do so more and more

• object-oriented programming has gained widespread acceptance / preference as an alternative to flat data structures

The contributing editor acknowledges the following extract from a recent Automated Logic white paper as a useful contribution to the object-orientated programming point:

Since BACnet and EIB objects and LonMark functional profiles are information models and XML is a modelling language, we could express these high level information models in XML and in so doing make them compatible with the emerging Web services architecture. Because of the flexibility of XML and the web services architecture, these high level models could be expanded to include other types of facility-related (but not necessarily building automation-related) information. If each building automation protocol developed its own XML model, however, we would have similar but incompatible system models. Today’s problems of translating from one protocol to another at the building controller level would become tomorrow’s translation problems at the Web services level. What’s needed is a unified system model, in XML, that can be used by any building automation protocol.

The contributing editor suggests the oBIX initiative at OASIS is a good thing to support but the editor also acknowledges the BACnet work in their extension of their objects to XML ( and to KNX). What is needed is a unified model, oBIX can achieve this task the quickest and especially with help from BACnet such that unification at XML schema level is the best option for the end-user and supply chain.

• [an error occurred while processing this directive] international standardisation ( ISO ) [ not just ANSI (US) or CEN / CENELEC  (Europe) ] is important for manufacturers for their security of product development choices and for end-users investment choices.

new proprietary developments with the very latest bleeding edge technology in fact generate fear, uncertainty and doubt, prove to be mostly ineffectual in the marketplace and reduce the market size due to the FUD. Innovation on the agreed international standards is the better way forward;  that is to say take the best open system source codes we have and improve them – together as a community;  this could be LonMark System with oBIX-OASIS or it could be the Konnex Association with BACnet and of course if the XML schema at the web service level are easily / directly translatable then Client investments are well made.

• interoperability of all products is the big deal from this contributing editor’s point of view for all solutions and interoperability is the best way to provide value and cost benefits – please refer to the virtual building head quarters for LonMark at www.LonMark.org

this issue is a system selection unique selling point; openness must be the ability to buy from a range of products for all building automation functions and from a large choice of manufacturers and be supported now and in the future by those manufacturers and the contracting business, the products need to provide seamless systems with interoperation between all companies and it must work commercially for all buyers and users.

•  2-tier solutions will prevail

• Finally in the contributing editor’s basis of argument and in operational terms for all larger buildings it is preferable that all device profiles are down-loadable and upgradeable on appropriate reasonably speedy bandwidth media; therefore all devices will be significantly software based.

This last argument suggests LON is preferable over KNX for the larger buildings;  in simpler or medium to small buildings KNX trained installation electricians can be appropriate. LON trained system integrators provide the intellectual resource for LON projects. The fundamentally different basis of installation between KNX and LON is electrician or system integrator.  BACnet is inappropriate at the lower tier; a system integrator is always necessary for a BACnet implementation at the management layer over the stack.  BWP tend to major in new installations of larger buildings therefore the LonMark System is a natural choice, BWP recommend “Web Services” in its simplest form at the head end of fully integrated systems.

the Technical Standards:

• this contributing editor acknowledges the following extract from a recent Automated Logic white paper as a useful contribution to make a point on the “web services” issue:

It should also be mentioned that this push toward Web services architecture should not be interpreted as an end to “standard” protocols. Web Services are useful as a computer-to-computer or software-application-to-software-application interface, but they will remain an “overkill” for some time to come as a device-to-device interface. While it might be possible to expose information as XML at a building-controller level, it would not be practical / cost effective to do so at a zone or unitary-controller level. Web services should be viewed more as a successor to OPC than a replacement for BACnet, KNX, or LON.

XML, TCP/IP, or even Web services alone cannot provide interoperability between vendors. In order for interoperability to occur, vendors must not only agree on HOW they will communicate, but also on WHAT they will communicate. Because they include a high-level abstraction of what information is to be communicated, BACnet, KNX, and LonMark all provide the WHAT component of interoperability. By combining these information models with XML, and expanding the objective to include other non-HVAC related aspects of the facility, Web services can provide an information platform that is high-level, cross-platform, cross-discipline, and multi-vendor.

• [an error occurred while processing this directive] this contributing editor acknowledges the following extract from the KNX web site - CENELEC officially ratified a new set of standard parts of the EN 50090 standard series. European Standardization on Home and Building Electronic Systems, (HBES). The basis for this achievement was laid down in June 2000 when CENELEC and Konnex Association signed a Cooperation Agreement for which Konnex committed itself to advise on and submit inputs regarding HBES. In this sense, Konnex submitted at the end of 2001 the necessary input for the following additional parts of EN 50090:

  EN 50090-3-2: User process for HBES Class 1
  EN 50090-4-1: Application layer for HBES Class 1
  EN 50090-4-2: Transport & network layers, and general parts of data link layer for HBES Class 1
  EN 50090-7-1: Management Procedures
  EN 50090-5-2: Network based on HBES Class 1, Twisted Pair
  After a positive vote within CENELEC TC 205 in June 2003 and the latter ratification by the CENELEC Technical Board, these new parts have been fully ratified and set for announcement and publication in the shortest delay.
  http://www.cenelec.org/Cenelec/CENELEC+in+action/Horizontal+areas/ICT/TC205.htm
  
  KNX does have a link to BACnet, see CENELEC EN 50090, European Standardization on Home and Building Electronic Systems, (HBES), KNX works at 9,600 bits per second and eventually a KNX installation always consists of a set of devices connected to the bus or network. Every facet is ultimately realized in and through the devices. All of these devices adhere to a number of logical node architectures for devices harbouring resources and implementing the protocol. Models vary according to node capabilities, management features and configuration modes; and not to forget, according to its role in the network, e.g. typical “application (end) device”, configuration master, router, gateway etc. KNX also standardizes certain general-purpose device models, such as for Bus Coupling Units (BCUs) or Bus Interface Modules (BIMs), mainly used in combination with the programming tool (ETS) and downloadable application programs. Specifically for platforms like these, supplementary “hosting” Application Programming Interfaces are defined. Together with the characteristics of the Configuration Modes, these device models are all laid down in the Profiles.

BACnet

• This contributing editor acknowledges the following extracts from ASHRAE web–based press releases : the first was entitled BACnet confirm approval as an International Standard; BOSTON, Massachusetts, February 5, 2003 - BACnet®, the ANSI/ASHRAE SSPC 135 standard data communication protocol for building automation and control networks, will be published as an international standard by the International Organization for Standardization as ISO 16484-5. The announcement that BACnet had been approved for publication as an ISO standard was made at ASHRAE's winter meeting, held January 25-29 2003 in Chicago.  Subsequently, it was announced that BACnet is on track for approval by the European Committee for Standardization (CEN) as an official European Standard, EN/ISO 16484-5. "Adoption as a world standard through the ISO is a vote of confidence in both the technical quality of BACnet and in the open process of enhancing and maintaining the standard over time," said Steve Bushby, Chairman of ASHRAE SSPC 135. While several ASHRAE standards are referenced as part of international standards, Standard 135 is only the second in some 10 years to be adopted in its entirety.  "For these two organizations (ISO and CEN)  to completely adopt Standard 135 signifies the importance of BACnet to the international engineering community," said ASHRAE President Donald Colliver, Ph.D., P.E. "This recognition shows that BACnet is an authoritative source for building control guidance."

entitled BACnet Web Services Initiative Goes to Public Review. (6/04) Nashville, TN. After months of intense effort by the Web Services Task Team of the BACnet/XML Working Group, SSPC 135 has unanimously voted to recommend public review of an addendum to BACnet-2004 that specifies the use of "web services" to provide a means to integrate building automation and control systems with other enterprise computing applications. Web services provide for computer-to-computer applications many of the same advantages that the World Wide Web provides for human-to-computer information access. Potential uses of the technology include simplifying access to building energy and performance data for inclusion in spreadsheets and other management reports; accessing equipment run-time data for use by maintenance management systems; allowing tenant access to, and control of, space temperature setpoints; coupling of room scheduling with ventilation and comfort control; and many more.

the new addendum is in two parts.

The first proposes an Annex M to BACnet that defines the BACnet Web Services interface, BACnet/WS. This interface is intended to be "protocol neutral" in that the defined web services can be used with any underlying protocol including BACnet, Konnex, MODBUS, LON or legacy proprietary protocols. This has been accomplished by defining an application program interface (API) to read and write the common elements of all building automation and control systems such as values, schedules, trend logs, and alarm information using services such as 'getValue' and 'setValue' that use a simple "path" to define the intended data source. An example of such a path would be: "/ABC HQ/Conference Room A/Space Temperature". The proposed standard also provides powerful mechanisms for "localization" where certain types of data such as time, date and numbers can be formatted according to local custom and language. Text names and descriptions may also be accessed according to the local language. Several manufacturers have already indicated their intention to display Annex M gateway products at the AHR show in January in Orlando, 2005.

The second part of the addendum contains an addition to BACnet's Annex H, Combining BACnet Networks with Non-BACnet Networks that prescribes the gateway mapping specifically to and from BACnet messages.

 the combined effect of the BACnet/WS annexes will be to provide a set of generic web services that can potentially interface to any building automation protocol as well as to describe exactly how this interface would work with underlying BACnet systems.

• [an error occurred while processing this directive] Addenda to ASHRAE Energy, BACnet Standards Approved by ANSI; Release Date: 03/30/2004; ATLANTA - Eight addenda to the American Society of Heating, Refrigerating and Air-Conditioning Engineers' (ASHRAE) energy conservation and building controls network standards have been approved by the American National Standards Institute (ANSI). Three addenda to ANSI/ASHRAE Standard 135-2001, BACnet - A Data Communication Protocol for Building Automation and Control Networks were approved. This is an open, consensus-developed standard in the building controls industry.

Addendum 135a changes the way schedules are represented and maintained in BACnet systems.
Addendum 135c contains eight new features that include enhancements to the life safety objects and services and the ability to represent utility meters and other measuring devices that provide pulsed outputs.
Addendum 135d contains information on how to interconnect BACnet devices with devices that use the EIB/Konnex protocol.

• LonMark System and oBIX / OASIS are all progressing apace from a later start than BACnet and KNX, see web pages for latest developments and monitor the LonMark International web site for updates.

http://www.cenorm.be/CENORM/BusinessDomains/TechnicalCommitteesWorkshops/CENTechnicalCommittees/WP.asp?param=6228&title=CEN/TC%20247

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix

http://www.lonmark.org/news/in0404_world_planner.htm

CONTACT Dr. J Hertel, LonMark International European Executive for more information.

a Marketplace Appraisal; LON – KNX - BACnet

From last month’s article by this contributing editor, LonMark International, the “new organisation” launched at the ASHRAE show in Anaheim this year 2004, prospective LonMark members from Europe are distributed as listed here, 669 No. (June 2004); all groups are continuing to expand such that the 1,000 LonMark member target is quite possible; the 669 members are mostly separate to the 300 person old LonMark Interoperability Association membership and as well there are a number of LonUsers/LonMarkers around the world, including organisations in Japan, Australia/NZ, Korea, Singapore and China. This is a major worldwide association, for example in comparison Profibus, the industrial control network bus, has 1,200 members. Please note the following European membership:

Please note the twelve sponsor members (June 2004) of LonMark International are:

[an error occurred while processing this directive] Next month
Come back for advice on buying Open Systems, procurement of such a choice of solutions and products and not complicated is a “trick”.

The programme we have for you continues to run as follows:
1. April "Intro"
2. May "VBHQ part 1",  or go to www.LonMark.org follow the VBHQ motif
3. June "VBHQ part 2", or go to www.LonMark.org follow the VBHQ motif
4. July "LonMark International" and the "LonMark System" , or go to www.LonMark.org follow the VBHQ motif
5. August "Open Systems Standards”, or go to www.LonMark.org follow the VBHQ motif
6. September "Procurement Advice"
7. October "Everyone Wins"
8. November "Consultants Design Notes and Openness is Safer"
9. December "Case Study Notes for Consultants"

About the Author
Paul D.J. Mason B.Eng (Hons), C.E.O. at BWP plc who are based in London and the East Anglia region United Kingdom. BWP have an affiliate office, DWP, in Paris, France. BWP is a niche high quality building services consulting engineering design service company and specialist in "green" engineering. BWP currently employ 27 people. Paul (45) has a career encompassing Marine Engineering Royal Navy, the Property Services Agency of the UK Department of Environment, University as a mature student, and since 1989, with 2 private sector building services design companies "CJP" and since 1997 "BWP". Since 1999 BWP primarily specify the LonMark System.

BWP are members of LonUsers UK, Associate members of LonMark International, the Intelligent Building Group, the British Council of Offices, Building Services Research and Information Association, Chartered Institute of Building Services Engineers and the Association of Consulting Engineers. Paul is an invited Contributing Editor through 2004 with www.automatedbuildings.com.