Loading ...
Sorry, an error occurred while loading the content.

BACnet IT Working Group: operating assumptions

Expand Messages
  • James F. Butler
    My goal for the BACnet IT working group is to prepare the BACnet committee for a possible major revision to the BACnet protocol. This is based on my view that
    Message 1 of 2 , Oct 29, 2009
    • 0 Attachment
      My goal for the BACnet IT working group is to prepare the BACnet committee for a possible major revision to the BACnet protocol. This is based on my view that BACnet, as it is currently designed, will not meet future market requirements/expectations for building automation systems that we can already foresee. (See document JB-029-1 "Vision for BACnet IT" in our Yahoo Group's Files area.)

      In order to accomplish my goal the BACnet IT working group needs to operate with a different set of assumptions than some of the other working groups. In particular:

      1. We should not be afraid to consider a change to any aspect of BACnet if such a change would make BACnet better in the long term.

      2. If we decide that a major revision to BACnet is warranted, we will need a strategy for achieving a high level of interoperability between new BACnet systems and existing BACnet systems at a reasonable cost.

      I do not want you to get the impression that it is our job to rewrite BACnet within the BACnet IT working group. On the contrary, our working group currently has a rather limited charter:

      "The BACnet IT working group's initial task will be to enumerate the general communication requirements of building automation systems that will be deployed over the next several years and evaluate BACnet against those requirements. To the extent that BACnet does not meet those requirements, the working group will discuss, at a high level, how BACnet could be modified or redesigned in order to better meet those requirements. Based on the outcome of those discussions, the working group members might initiate projects to investigate various design options."

      The purpose of developing a set of requirements first is to give us a basis for making decisions about the design of a future BACnet. These requirements are likely to be rather marketing-oriented at first; for example, what control applications and markets are we trying to serve using future BACnet-based systems? From there, we can derive a set of high-level technical requirements.

      I would like things to move along at a quick but reasonable pace. My goal is for us to be well into the discussion of technical requirements by our meeting in Orlando in January. In order to ensure that we move reasonably quickly, Cimetrics will be active contributor of content to the working group during the requirements phase. Charles Frankston, our Director of Software, has 30+ years of experience in the development and operation of IT systems, and he will be joining me on the working group. We will try to schedule two teleconferences before our Orlando meeting (probably in early December and early January), and those teleconferences will be focused on achieving a reasonable level of consensus on key issues.

      I welcome your feedback.

      Regards,

      - Jim Butler
    • Joel Bender
      ... I would like the group to consider issues of scalability . At Cornell we are seeing a variety of trends: - New facilities coming online with thousands of
      Message 2 of 2 , Oct 29, 2009
      • 0 Attachment
        James F. Butler wrote:

        > The BACnet IT working group's initial task will be to enumerate
        > the general communication requirements of building automation
        > systems that will be deployed over the next several years and
        > evaluate BACnet against those requirements.

        I would like the group to consider issues of "scalability". At Cornell
        we are seeing a variety of trends:

        - New facilities coming online with thousands of devices and
        hundreds of thousands of points
        - Server farms where servers can be dynamically provisioned and
        services can be re-deployed as demand changes (the reality
        side of the 'cloud computing' hype)
        - Enterprise scale identity and authorization (Kerberos, Windows
        Domain, OpenID)
        - User centric applications (what is happening in my office/lab)
        differentiated from technician centric (debug this subsystem)
        - Smart phone and PDA applications (smaller, focused presentation
        of content) differentiated from workstation applications
        (large screens, full Java/ActiveX/Flash platform)
        - Leaner web services (REST, JSON over SOAP)

        How can BACnet fit into these "web scale" systems?


        Joel
      Your message has been successfully submitted and would be delivered to recipients shortly.