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

BACnet IT-WG meeting in Germantown, Maryland: May 11, 2010

Expand Messages
  • James F. Butler
    Logistics The BACnet IT-WG meeting in Germantown will be on Tuesday May 11, 2010, from 8 a.m. until 9:30 a.m. at Montgomery College, Room GB105. The GB
    Message 1 of 9 , May 7, 2010
    • 0 Attachment
      [bacnet-it-wg] Teleconference January 15, 2010 at 11:00 a.m. EST

      Logistics

       

      The BACnet IT-WG meeting in Germantown will be on Tuesday May 11, 2010, from 8 a.m. until 9:30 a.m. at Montgomery College , Room GB105.  The GB building is located on Goldenrod Lane .  The IP-WG will meet immediately after the IT-WG meeting.

       

      Directions to the Montgomery College campus in Germantown : http://www.montgomerycollege.edu/maps/gvic.html

       

      Parking Instructions: Park in the GB parking lot in any white line (student) parking space, obtain a Temporary Parking Permit at the SSPC 135 meeting and properly display the permit in your vehicle.

       

      Meeting Discussion Topic

       

      I believe that BAS-IT convergence will require that BAS products become more IT friendly.  But what does that mean in concrete terms?  How might that affect the future of BACnet?  Please read http://bacnetit.cimetrics.com/bin/view/BACnetIT/ITFriendliness for background, and come prepared to state your opinions about how building automation products could become better citizens on corporate networks.

       

      Also, if you haven’t already read Andy McMillan’s article on this topic (“Good Fences Make Good Neighbors”), I recommend that you do so prior to the meeting: http://www.automatedbuildings.com/news/jun09/columns/090531120404mcmillan.htm

       

      From this discussion, we will attempt to capture some use cases and/or requirements that will help guide the next phase of our work.

       

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

       

      - Jim Butler

      BACnet IT-WG Leader

      mailto:jimbutler@...

       

    • 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 2 of 9 , Jun 18 2:01 PM
      • 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 3 of 9 , Jun 21 7:53 AM
        • 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 4 of 9 , Jun 21 9:22 AM
          • 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 5 of 9 , Jun 21 4:25 PM
            • 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 6 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.