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

BACnet IT-WG meeting in Albuquerque: June 27, 2010

Expand Messages
  • James F. Butler
    Germantown Meeting Recap During our meeting in Germantown in May, we discussed the concept of IT friendliness and what that might mean for BACnet. The
    Message 1 of 9 , Jun 18, 2010
    • 0 Attachment
      [bacnet-it-wg] Teleconference January 15, 2010 at 11:00 a.m. EST

      Germantown Meeting Recap

       

      During our meeting in Germantown in May, we discussed the concept of IT friendliness and what that might mean for BACnet.  The background document is posted here: http://bacnetit.cimetrics.com/bin/view/BACnetIT/ITFriendliness.  Also, if you haven’t already read Andy McMillan’s article on BAS-IT convergence (“Good Fences Make Good Neighbors”), I recommend that you do so: http://www.automatedbuildings.com/news/jun09/columns/090531120404mcmillan.htm

       

      Albuquerque Meeting

       

      The BACnet IT-WG meeting in Albuquerque (NM) will be on Sunday June 27, 2010, from 8 a.m. until 9:00 a.m. at the Albuquerque Convention Center in the Santa Ana room.  The BACnet IP-WG will meet immediately after the IT-WG meeting.  These meetings are part of ASHRAE’s Summer Meeting.

       

      A small group of us are putting the finishing touches on a set of draft requirements for BACnet IT, which will be posted on the BACnet IT-WG TWiki on Monday.  I’ll send a separate message about this on Monday.  This will be “required reading” prior to the Albuquerque meeting.

       

      We have a one-hour meeting slot in Albuquerque .  The meeting will begin with a presentation on BACnet IT requirements, and a discussion will follow.

       

      Future Meetings

       

      The next official BACnet committee meeting is expected to be held in late October or early November in Atlanta .  However, I am thinking about the possibility of holding a one- or two-day “BACnet IT Summit ” some time before the Atlanta meeting, possibly in September.

       

      Feel free to contact me if you have any questions or ideas.

       

      - Jim Butler

      BACnet IT-WG Leader

      mailto:jimbutler@...

       

    • Charles Frankston
      I ve put a page up on the BACnet IT TWiki: http://bacnetit.cimetrics.com/bin/view/BACnetIT/RequirementsSummary, with some strawman BACnet IT requirements
      Message 2 of 9 , Jun 21, 2010
      • 0 Attachment

        I’ve put a page up on the BACnet IT TWiki: http://bacnetit.cimetrics.com/bin/view/BACnetIT/RequirementsSummary, with some “strawman” BACnet IT requirements that I’d like to use as a starting point for the conversation in Albuquerque .  I would welcome discussion of these points via this mailing list in the next few days before the meeting.

         

      • Carl Neilson
        1) A minor point: Need to find a service by type (Who-Has) should be Need to find an object by name or by identifier (Who-Has) 2) I am not sure I agree
        Message 3 of 9 , Jun 21, 2010
        • 0 Attachment
          1) A minor point:
          Need to find a service by "type" (Who-Has)
          should be
          Need to find an object by "name" or by "identifier" (Who-Has)


          2) I am not sure I agree with:
          It must be possible to aggregate formerly distinct BACnet
          systems into a single BACnet internetwork and avoid name collisions
          without requiring a potential scan and rename of all devices.

          This does not hold for any most networks that are deployed as private
          self-contained networks. When they are made no longer private, or
          multiples are joined, there may be the need to reworked naming and
          numbering. E.g. if two private IPv4 networks of PC are connected and
          they both contain a bank of servers named FileServer, PrintServer, and
          SuperPrivateServer, then renaming of the servers and reworking of
          application links to them will be required.

          I think that in order to guarantee that arbitrary disparate BACnet
          internetworks can be joined, one would need a guaranteed globally unique
          identifer assigned to, at the very least, each independent BACnet
          internetwork (assuming then that all entities within the network are
          scoped by that ID, and that the joining of the networks would not overly
          mix the entities losing the original network areas). Or a globally
          unique ID would need to be defined per device.

          Given that this is not something that it prevalent in the IT world
          today, is it really a fundamental requirement of BACnet/IT (I would not
          argue the merits of the feature, just whether or not it is fundamentally
          required for this task).


          3) Can sufficient security not be provided for many products in many
          installations by the infrastructure?

          For very small equipment-only installations, not tied into IT networks,
          little or no security is probably sufficient. Physical security
          (conduit, locked boxes) would be sufficient in almost all situations
          that require some level of security.

          For large installations that run on IT networks, the use of physical
          security (locked boxes, conduit, intrusion detection systems), managed
          hubs with MAC address matching (only allowed MACs can pariticipate),
          VPNs (segregation of traffic with a restricted number of connection
          points to the larger world) and firewalls (gatekeeping at the points of
          connection) provide more than adequate security for most BAS
          installations.

          For those installations that are in between, there is a need for either
          secure BAS products (but may be just the infrastructure products that
          have it), or better trained BAS technicians that can setup IT equipment
          to provide secure networks.

          As for permissions, is that not normally applied by the UI and/or the
          firewall/gateway into the system. Is there really an expectation that a
          thermostat will either contain a database of users or will query a
          security server to check if the requestor has permission to change the
          setpoint?

          While secure product will be required (or at least should be required)
          by many installations, I do not believe that it would be, or should be,
          required by all installations. Given that security is about
          understanding and managing risk (effort versus probable loss), the tools
          that exist for an IT network should be sufficient for many
          installations. This leaves it open for cost recovery on secure products
          by charging more for them, but only in those cases where it is truly
          required.

          Carl


          ________________________________

          From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com]
          On Behalf Of Charles Frankston
          Sent: Monday, June 21, 2010 7:53 AM
          To: 'bacnet-it-wg@yahoogroups.com'
          Subject: [bacnet-it-wg] BACnet IT proposed requirements summary




          I've put a page up on the BACnet IT TWiki:
          http://bacnetit.cimetrics.com/bin/view/BACnetIT/RequirementsSummary
          <http://bacnetit.cimetrics.com/bin/view/BACnetIT/RequirementsSummary> ,
          with some "strawman" BACnet IT requirements that I'd like to use as a
          starting point for the conversation in Albuquerque. I would welcome
          discussion of these points via this mailing list in the next few days
          before the meeting.
        • Charles Frankston
          Carl - Thanks for the reply. Let me see if I can elaborate on some of the points: 2) I am not sure I agree with: It must be possible to aggregate formerly
          Message 4 of 9 , Jun 21, 2010
          • 0 Attachment

            Carl – Thanks for the reply.  Let me see if I can elaborate on some of the points:

            2) I am not sure I agree with:

            It must be possible to aggregate formerly distinct BACnet
            systems into a single BACnet internetwork and avoid name collisions
            without requiring a potential scan and rename of all devices.

            This does not hold for any most networks that are deployed as private
            self-contained networks. When they are made no longer private, or
            multiples are joined, there may be the need to reworked naming and
            numbering. E.g. if two private IPv4 networks of PC are connected and
            they both contain a bank of servers named FileServer, PrintServer, and
            SuperPrivateServer, then renaming of the servers and reworking of
            application links to them will be required.

            Yes, when two private IP networks are joined, IP addresses and host names may need to be changed.  But the point is that ht IT community has efficient means and tools for dealing with this.  In most IT environments, the vast bulk of IP addresses are assigned via DHCP.  So a site-wide change can often be done by simply changing the DHCP parameters.  The major point here being that most IT protocols don’t persist IP addresses (beyond the lifetime of a particular connection/task), so such a change doesn’t cause major disruption.

            Similarly for hostnames, domain namespaces are hierarchical, and many organizations make use of that.  So for example, suppose a xyz company of Vancouver buys abc company of Boston .  Suppose xyz operates their internal network as xyz.net.  XYZ & ABC can merge their networks without renaming all of their hosts by saying the local domain of the new Boston office is boston.xyz.net, and the local domain of the Vancouver office is vancouver.xyz.net (if it wasn’t already).  This is the “internet” way of handling the merger scenario.

            The main point of adopting what has become the world-wide IT standard – i.e. using IP as *the* network layer, is that the IT/Internet world has already created workable, sometimes even elegant, solutions to many of these issues and BACnet IT should use these solutions wherever possible.

            3) Can sufficient security not be provided for many products in many
            installations by the infrastructure?

            For very small equipment-only installations, not tied into IT networks,
            little or no security is probably sufficient. Physical security
            (conduit, locked boxes) would be sufficient in almost all situations
            that require some level of security.

            The main point is requiring that all equipment which claims to be BACnet IT compliant be prepared to support a BACnet IT specified security story.  Whether installations could, should, or would turn it on is another matter.  Security that is an optional, possibly extra-cost option, is unlikely to succeed. 

            But in fact, I believe even smaller installations would, or *should*, run with security enabled.  We had some of this discussion at Germantown .  I think increasingly it is becoming less and less acceptable for even small networks to not have security.  We discussed the 7/11 example, where it’s quite likely the HVAC network would be aggregated and remotely monitored on the same data link used for the cash registers.  It’s just not worth fooling around with letting any part of that be penetrated.

            The key, or perhaps the challenge, is creating security procedures that are simple and commonplace.  Again, the reason to look to the IT world for solutions here is that they’ve already faced this – particularly in wireless scenarios.  But even on wired networks, I think you’ll find that fewer and fewer packets are traversing your corporate network in the clear anymore.  Most enterprises have recognized that it’s just too easy to plug something into an active jack and start causing mischief..  In a BAS it’s potentially even easier when every thermostat, or even every light switch has a physical connection to the BAS.

            As for permissions, is that not normally applied by the UI and/or the
            firewall/gateway into the system. Is there really an expectation that a
            thermostat will either contain a database of users or will query a
            security server to check if the requestor has permission to change the
            setpoint?

            I think the answer simply is “yes”.  I can think of enterprise scenarios where very fine-grained access control is useful and desirable.  Even today, thermostats of often locked-down – i.e. the occupants can’t fool with them in large commercial office environments.  So the HVAC automatically shuts off at 6PM, but you’re working late.  Well, today that employee might have an after-hours phone number for facilities management and can maybe call and get someone who might know how to tweak the controls workstation.  What if they could just do this from their PC instead?  The corporate enterprise management system could check that they were indeed and employee with an office on that floor, who was permitted to do that override.. and this would likely be tied in to the card key that gave him/her physical access, etc.  (Hint: no, the database will almost certainly not be contained within the thermostat.)

            So, OK, the above is a complex scenario, and it would likely take a while to work that all out.  But we should be designing BACnet IT to be the protocol for the next 20 years..

             

          • Charles Frankston
            Has been posted to the BACnet IT Wiki: http://bacnetit.cimetrics.com/bin/view/BACnetIT/StrawMen
            Message 5 of 9 , Jul 1, 2010
            • 0 Attachment

              Has been posted to the BACnet IT Wiki: http://bacnetit.cimetrics.com/bin/view/BACnetIT/StrawMen

               

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