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

RE: Integration of multiple BINs

Expand Messages
  • Isler, Bernhard
    Please see nested in below... Bernhard Isler Siemens Switzerland Ltd Building Technologies Division From: bacnet-it-wg@yahoogroups.com
    Message 1 of 10 , Oct 18, 2012
    • 0 Attachment

      Please see nested in below...

       

      Bernhard Isler
      Siemens Switzerland Ltd
      Building Technologies Division

      From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of ThomasJBrennan@...
      Sent: Thursday, October 18, 2012 2:13 PM
      To: bacnet-it-wg@yahoogroups.com
      Subject: [bacnet-it-wg] RE: Integration of multiple BINs

       




      Couldn’t we simplify this a little to permit multiple BINs:

      -          Multiple BINs cannot speak to each other (through the NTB) – they can’t do it today, so nothing is lost here – this avoids BIN Device ID collision

      [BI] Yes, fully agree. This is why in BI-041 the integration scenario IS-2 is out of scope at this time.

       

      -          NTB Devices have the same Device IDs represented to all BIN networks.  Recommended practice is to find an unused range on all BINs and use that for the NTB Device IDs.  If no such range can be found, we can’t help you integrate multiple BIN systems.

      [BI] I think this could be an acceptable limitation. Currently, there is no restriction on using the entire Device Instance range available. Collisions could occur, but clever engineering tools could find ways to minimize and/or automate a Device ID re-assignment for freeing up some range. Every next BIN that is being integrated into the NTB space may cause the same process again.  

      -          NTB gateways can treat each BIN similar to a software namespace and prepend that to the BIN’s Device IDs, eg BIN1::DevID_12345  (whatever form that takes)

      [BI] Yes, this is along the ideas (hopefully) outlined. The use cases attempted to be solved were:

      a)      Devices could be migrated across the border, from being a BACnet Device to be an NTB Device in the NTB space. This move should not break references in the device and to the device. So the NTB Device Address, <UET>.DevID_12345, would still just identify the device, and not be related to any structure where it sits.  Making the combination of UET and Device ID being unique would facilitate this.
      The references in the BIN were the device was are maintained if the NTB Device is now proxied into the BIN using the same BACnet Device ID again.

      b)      Merging NTB systems should not cause breaks of references. There should be some way to avoid that everyone is using “BIN1”. The NTB as outlined would ensure a global uniqueness of the NTB Device Address, independent of its place in the network structure or current NTB space. The NTB space limit is built at IP level, such as by routers and firewalls.

      c)       PKI certificates for HTTPS should not be bound to the FQDN of the device, but something above DNS. DNS names appear to be changed too often to be acceptable for a BAS, cf. the two step approach for NTB Device Address resolution to the IP address of the host. If there is a convention that the NTB Device Address allows encoding it using the DNS name character set, then the PKI certificates can be bound to it.

      d)      An NTB proxy needs to know one UET, which it can use for all the BACnet Devices of one BIN it is proxying.

      The NTB Device Address or parts of should not be used to mean a BIN. A BIN should be represented using an NTB Group. The NTB Group address format should contain some type information. One of the types could be “BIN”.  A lot of other NTB Group types related to legacy integration come to mind, but may be enumerated in BI-040.

       

       

      From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Isler, Bernhard
      Sent: Thursday, October 18, 2012 4:01 AM
      To: bacnet-it-wg@yahoogroups.com
      Subject: [bacnet-it-wg] Integration of multiple BINs

       

       

      Hi all,

       

      Back to the teleconference discussion we had on Tuesday, it became obvious that:

       

      -          The requirement for being capable of integrating multiple BINs implies a larger increase in complexity. This includes:

      -          Introduction of some additional identification, for dealing with colliding Device IDs.

      -  &n bsp;       This additional identification has to be incorporated into the data model, mainly in references.

      -          This means that the data model is modified.

      -          Proxied NTB Devices require BIN specific Device IDs, so that an NTB Device can always participate in multiple BINs.

      -          For this, appropriate proxying between legacy BACnet and NTB is compl ex.

      -          In particular for setting references, for reading references, and mapping of Device object Object_Identifier on the far side of the proxy.

       

      Do we really want to pursue this requirement?

       

      Best,

      Bernhard

       

      Bernhard Isler
      Siemens Switzerland Ltd
      Building Technologies Division
      IC BT CPS GDT AS
      Gubelstrasse 22
      CH-6301 Zug, Switzerland

      Tel: +41 (41) 724 33 87
      Mob: +41 (79) 561 77 23
      Fax: +41 (41) 723 48 94

      mailto:bernhard.isler@...
      http://www.siemens.com/buildingtechnologies

      Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

       




    • Carl Neilson
      Bernhard et al, Maybe I misunderstood the conversation we were having, but I did not think we were talking about integrating multiple BINs but rather having
      Message 2 of 10 , Oct 18, 2012
      • 0 Attachment

        Bernhard et al,

         

        Maybe I misunderstood the conversation we were having, but I did not think we were talking about integrating multiple BINs but rather having NTBs participate in multiple BINs.

         

        The problem with fixing a DeviceId across BINs is that it assumes that all BINs are known when a device attaches to the BINs. But this is not the case as a new BIN can be added at any time. While a device could change its device id to remaining unique in all, existing references in existing BINs would need to be changed.

         

        In thinking through the issues…

         

        One problem of participating in multiple BINs is with using the correct device identity when referring to a device (be it the source/local NTB device or a different NTB device). In the new model an NTB device has multiple identities:

         

        I-Am (NTB-Id, (list of (BinId, DeviceId), …)

         

        And when it registers with the name server / device discovery server, I expect that it will provide all identities. I also expect that the discovery mechanism will return (or be able to return) all identities when looking up a device.

         

        When referring to a device, the correct identity needs to be used depending on the context. This is not a problem in addressing services, but is a problem in data conveyed in parameters of a service. Where the encoding NTB device understands the data contained in the communication, it is able to fixup any device references (assuming the ability to resolve incorrect aliases to correct aliases for the target context).

         

        This still leaves the problem of what an NTB/cross-BIN reference looks like. Keeping in mind that each of a device’s identities are unique, any one of the identities can be placed into the reference:

         

                        deviceref ::= CHOICE {

                                        [0]          NTB-DeviceId    BACnetNTBDeviceId,  

                                        [1]          BIN-DeviceId     BACnetBINDeviceId

                        }

         

                        ( (deviceref), (objectId), (propertyId), (arrayindex) )

         

        As discussed in the telco, the NTB device would be responsible for converting the (deviceref) to the correct alias before responding.

         

        The problem becomes more complex when data is extracted from one device and stored in another such as when an EventNotification is received and placed into a log. If the notification parameters contain device references, then the device references needs to either be updated or imply the BIN. If the EventNotification is of a type that the logging device does not know, any encapsulated device references cannot not be updated.

         

        So while no direct communication is occurring between BINs, indirect communication can occur if objects are allowed to reside in multiple BINs, or if data is able to be taken from an object in one BIN and placed into an object in another BIN.


        This seems to require that data sources be included (where did the data originally come from). Any data that was not fixed up would not be able to be accurately transferred to a different BIN. The questions for me are:

                        Where does this problem occur?

                        In how many different use cases do we expect it to occur?

                        What problems are expected if the data is transferred without being fixed up?

                        Can non-fixed up data be dropped in a manner that would not break implementations?

         

         

        Carl

         

         

        From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Isler, Bernhard
        Sent: Thursday, October 18, 2012 1:01 AM
        To: bacnet-it-wg@yahoogroups.com
        Subject: [bacnet-it-wg] Integration of multiple BINs

         

         

        Hi all,

         

        Back to the teleconference discussion we had on Tuesday, it became obvious that:

         

        -          The requirement for being capable of integrating multiple BINs implies a larger increase in complexity. This includes:

        -          Introduction of some additional identification, for dealing with colliding Device IDs.

        -  &n bsp;       This additional identification has to be incorporated into the data model, mainly in references.

        -          This means that the data model is modified.

        -          Proxied NTB Devices require BIN specific Device IDs, so that an NTB Device can always participate in multiple BINs.

        -          For this, appropriate proxying between legacy BACnet and NTB is comple x.

        -          In particular for setting references, for reading references, and mapping of Device object Object_Identifier on the far side of the proxy.

         

        Do we really want to pursue this requirement?

         

        Best,

        Bernhard

         

        Bernhard Isler
        Siemens Switzerland Ltd
        Building Technologies Division
        IC BT CPS GDT AS
        Gubelstrasse 22
        CH-6301 Zug, Switzerland

        Tel: +41 (41) 724 33 87
        Mob: +41 (79) 561 77 23
        Fax: +41 (41) 723 48 94

        mailto:bernhard.isler@...
        http://www.siemens.com/buildingtechnologies

        Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

      • Isler, Bernhard
        See nested in below... Bernhard Bernhard Isler Siemens Switzerland Ltd Building Technologies Division From: bacnet-it-wg@yahoogroups.com
        Message 3 of 10 , Oct 19, 2012
        • 0 Attachment

          See nested in below...

           

          Bernhard

           

          Bernhard Isler
          Siemens Switzerland Ltd
          Building Technologies Division

          From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Carl Neilson
          Sent: Thursday, October 18, 2012 10:26 PM
          To: bacnet-it-wg@yahoogroups.com
          Subject: [bacnet-it-wg] RE: Integration of multiple BINs

           




          Bernhard et al,

           

          Maybe I misunderstood the conversation we were having, but I did not think we were talking about integrating multiple BINs but rather having NTBs participate in multiple BINs.

          [BI] Yes, we were talking about having NTB Devices participate in multiple BINs.

           

          The problem with fixing a DeviceId across BINs is that it assumes that all BINs are known when a device attaches to the BINs. But this is not the case as a new BIN can be added at any time. While a device could change its device id to remaining unique in all, existing references in existing BINs would need to be changed.

          [BI] Yes, adding a new BIN may cause Device ID reassignments, somewhere. It could be in the BIN to add, or the NTB Device whose ID collides. Respective references would need respective adjustment.

           

          In thinking through the issues…

           

          One problem of participating in multiple BINs is with using the correct device identity when referring to a device (be it the source/local NTB device or a different NTB device). In the new model an NTB device has multiple identities:

           

          I-Am (NTB-Id, (list of (BinId, DeviceId), …)

           

          And when it registers with the name server / device discovery server, I expect that it will provide all identities. I also expect that the discovery mechanism will return (or be able to return) all identities when looking up a device.

           

          When referring to a device, the correct identity needs to be used depending on the context. This is not a problem in addressing services, but is a problem in data conveyed in parameters of a service. Where the encoding NTB device understands the data contained in the communication, it is able to fixup any device references (assuming the ability to resolve incorrect aliases to correct aliases for the target context).

           

          This still leaves the problem of what an NTB/cross-BIN reference looks like. Keeping in mind that each of a device’s identities are unique, any one of the identities can be placed into the reference:

           

                          deviceref ::= CHOICE {

                                          [0]          NTB-DeviceId    BACnetNTBDeviceId,  

                                          [1]          BIN-DeviceId     BACnetBINDeviceId

                          }

           

                          ( (deviceref), (objectId), (propertyId), (arrayindex) )

           

          As discussed in the telco, the NTB device would be responsible for converting the (deviceref) to the correct alias before responding.

          [BI] What becomes clear here is that there must be an identification of the BIN that is usable throughout in NTB for identifying the BIN name space. It appears that we cannot cover the use case that a BACnet Device can be converted into an NTB device with keeping the entire identification. Refer to my response to Tom yesterday.

           

          The problem becomes more complex when data is extracted from one device and stored in another such as when an EventNotification is received and placed into a log. If the notification parameters contain device references, then the device references needs to either be updated or imply the BIN. If the EventNotification is of a type that the logging device does not know, any encapsulated device references cannot not be updated.

          [BI] The NTB logging device should also log the identification of the space of the original source. For logging event notifications, this would mean respective extension of the BACnetEventLogRecord, to add the source space information (e.g. BIN ID).  A BACnet Device in another BIN consuming such a record from an NTB device would struggle

           

          So while no direct communication is occurring between BINs, indirect communication can occur if objects are allowed to reside in multiple BINs, or if data is able to be taken from an object in one BIN and placed into an object in another BIN.

          [BI] While I agree that the indirect communication can occur for NTB Devices that are proxied into multiple BINs, I see the second to be out of scope. A BACnet Device that is proxied into NTB should not further be proxied into a next BIN. Forwarding data between BINs should be on application level, with e.g. a kind of mirror objects.


          This seems to require that data sources be included (where did the data originally come from). Any data that was not fixed up would not be able to be accurately transferred to a different BIN. The questions for me are:

                          Where does this problem occur?

                          In how many different use cases do we expect it to occur?

                          What problems are expected if the data is transferred without being fixed up?

                          Can non-fixed up data be dropped in a manner that would not break implementations?

          [BI] I will go and address these questions in BI-041. I will go from:

          -          It is not a use case that data is exchanged between two BINs that are both connected to NTB. This should be excluded, it did not work before as well.

          -          Data from one BIN is invalid in another BIN, in particular IDs and references using such IDs.

          -          Data exchange between BINs need an application level mirror that is aware of how to mangle data for the target context.

          What I am planning to do:

          -          Narrow and enumerate the places where the problem may occur

          -          Enumerate the use cases, and propose a triage among those that apply and those that we should exclude

          -          Enumerate problems, requirements, behavior etc. when data is exchanged.

          Any help in this would be appreciated, e.g. in enumerating use cases and problems that are in mind.   

           

           

           

          Carl

           

           

          From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Isler, Bernhard
          Sent: Thursday, October 18, 2012 1:01 AM
          To: bacnet-it-wg@yahoogroups.com
          Subject: [bacnet-it-wg] Integration of multiple BINs

           

           

          Hi all,

           

          Back to the teleconference discussion we had on Tuesday, it became obvious that:

           

          -          The requirement for being capable of integrating multiple BINs implies a larger increase in complexity. This includes:

          -          Introduction of some additional identification, for dealing with colliding Device IDs.

          -  &n bsp;       This additional identification has to be incorporated into the data model, mainly in references.

          -          This means that the data model is modified.

          -          Proxied NTB Devices require BIN specific Device IDs, so that an NTB Device can always participate in multiple BINs.

          -          For this, appropriate proxying between legacy BACnet and NTB is comple x.

          -          In particular for setting references, for reading references, and mapping of Device object Object_Identifier on the far side of the proxy.

           

          Do we really want to pursue this requirement?

           

          Best,

          Bernhard

           

          Bernhard Isler
          Siemens Switzerland Ltd
          Building Technologies Division
          IC BT CPS GDT AS
          Gubelstrasse 22
          CH-6301 Zug, Switzerland

          Tel: +41 (41) 724 33 87
          Mob: +41 (79) 561 77 23
          Fax: +41 (41) 723 48 94

          mailto:bernhard.isler@...
          http://www.siemens.com/buildingtechnologies

          Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

           




        • Carl Neilson
          What I take from the statements below (from previous emails) is: An NTB device that participates in multiple BINs cannot arbitrarily map all of its objects
          Message 4 of 10 , Oct 19, 2012
          • 0 Attachment

            What I take from the statements below (from previous emails) is:

            An NTB device that participates in multiple BINs cannot arbitrarily map all of its objects into all BINs. The simple view of a device that has a single database of objects and each of those objects existing in all BINs in which the device participates does not work. At least not in cases where the objects have cross-device references.

            This implication is that devices which contain such objects are required to maintain separate object spaces (a schedule object cannot exist in multiple BINs if it contains any cross device references). All of the non-reference data can be mapped across BINs (the schedule data can exist in each BIN, but the List_Of_Object_Property_References cannot in the general case).

            The three main use cases that I see, are event notification / logging, scheduling and structured views.

            Scheduling - I think that the scheduling case is simple to solve and it could be solved in a standard way (maintain a List_Of_Object_Property_References per BIN, and from the NTB point of view there are either multiple lists or a conglomerate).

            Structured View - This case is probably simple to solve as well. Any view that crosses BINs is essentially outside the scope of any given BIN and probably should not be mapped into a BIN (the SV object would not exist in any BIN, only in NTB space).

            Event Notification / Logging – not sure.

             

            The other cases seem to be things that would naturally be contained within a single BIN.

             

            Object Types that can safely exist in multiple BINs:

            Accumulator

            Analog Input

            Analog Output

            Analog Value

            Binary Input

            Binary Output

            Binary Value

            Calendar

            File

            Group

            Loop

            Multistate Input

            Multistate Output

            Multistate Value

            Program

            Pulse Converter

            Load Control

            Credential Data Input

            CharacterString Value

            DateTime Value

            Large Analog Value

            BitString Value

            OctetString Value

            Time Value

            Integer Value

            Positive Integer Value

            Date Value

            DateTime Pattern Value

            Time Pattern Value

            Date Pattern Value

            Network Security

            Alert Enrollment

            Lighting Command

             

            Object Types that are able to contain direct cross device references:

            Averaging (Object_Property_Reference)

            Command (Action_List)

            Device (Device_Address_Binding, Time_Synchronization_Recipients, UTC_Time_Synchronization_Recipients, Active_COV_Subscriptions, Manual_Slave_Address_Binding, Slave_Address_Binding, Restart_Notification_Recipients)

            Event Enrollment (Object_Property_Reference, EventParameters.Command_Failure.Feedback_Property_Reference, EventParameters.Floating_Limit.Setpoint_Reference, EventParameters.Change_Of_Life_Safety.Mode_Property_Reference, EventParameters.Extended.Reference, EventParameters.Access_Event.Access_Event_Time_Reference)

            Life Safety Point (Member_Of)

            Life Safety Zone (Zone_Members, Member_Of)

            Notification Class (Recipient_List)

            Schedule (List_Of_Object_Property_References)

            Trend Log (Log_DeviceObjectProperty,

            Access Door (Door Members)

            Structured View (Subordinate_List)

            Trend Log Multiple (Log_DeviceObjectProperty)

            Access Point (Access_Event_Credential, Access_Doors, Zone_To, Zone_From)

            Access Zone (Credentials_In_Zone, Last_Credential_Added, Last_Credential_Removed, Entry_Points, Exit_Points)

            Access User (Members, Member_Of, Credentials)

            Access Rights (Accompaniment)

            Access Credential (Belongs_To, Last_Access_Point)

            Notification Forwarder (Subscribed_Recipients)

            Channel (List_Of_Object_Property_References)

             

            Object Type that are able to contain indirect/obscured cross device references (* == direct cross device references)

            Event Log (Log_Buffer)

            Global Group (Group_Members*, Present_Value, COVU_Recipients*)

            Carl


            This seems to require that data sources be included (where did the data originally come from). Any data that was not fixed up would not be able to be accurately transferred to a different BIN. The questions for me are:

                            Where does this problem occur?

                      ;       In how many different use cases do we expect it to occur?

                            What problems are expected if the data is transferred without being fixed up?

                            Can non-fixed up data be dropped in a manner that would not break implementations?

            [BI] I will go and address these questions in BI-041. I will go from:

            -           It is not a use case that data is exchanged between two BINs that are both connected to NTB. This should be excluded, it did not work before as well.

            -          Data from one BIN is invalid in another BIN, in particular IDs and references using such IDs.

            -          Data exchang e between BINs need an application level mirror that is aware of how to mangle data for the target context.

            What I am planning to do:

            -          Narrow and enumerate the places where the problem may occur

            -          Enumerate the use cases, and propose a triage among those th at apply and those that we should exclude

            -          Enumerate problems, requirements, behavior etc. when data is exchanged.

            Any help in this would be appreciated, e.g. in enumerating use cases and problems that are in mind.   

             

             

             

            Carl

             

             

            From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Isler, Bernhard
            Sent: Thursday, October 18, 2012 1:01 AM
            To: bacnet-it-wg@yahoogroups.com
            Subject: [bacnet-it-wg] Integration of multiple BINs

             

             

            Hi all,

             

            Back to the teleconference discussion we had on Tuesday, it became obvious that:

             

            -          The requirement for being capable of integrating multiple BINs implies a larger increase in complexity. This includes:

            -          Introduction of some additional identification, for dealing with colliding Device IDs.

            -  &n bsp;       This additional identification has to be incorporated into the data model, mainly in references.

            -          This means that the data model is modified.

            -&nbs p;         Proxied NTB Devices require BIN specific Device IDs, so that an NTB Device can always participate in multiple BINs.

            -          For this, appropriate proxying between legacy BACnet and NTB is comple x.

            -          In particular for setting references, for reading references, and mapping of Device object Object_Identifier on the far side of the proxy.

             

            Do we really want to pursue this requirement?

             

            Best,

            Bernhard

             

            Bernhar d Isler
            Siemens Switzerland Ltd
            Building Technologies Division
            IC BT CPS GDT AS
            Gubelstrasse 22
            CH-6301 Zug, Switzerland

            Tel: +41 (41) 724 33 87
            Mob: +41 (79) 561 77 23
            Fax: +41 (41) 723 48 94

            mailto:bernhard.isler@...
            http://www.siemens.com/buildingtechnologies

            Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

            &nbs p;





          • Carl Neilson
            Message 5 of 10 , Oct 19, 2012
            • 0 Attachment
            • Isler, Bernhard
              Hi all, I have uploaded a respective update of BI-041 to the Twiki. This is addressing issues brought up in the teleconference, and in this email thread.
              Message 6 of 10 , Oct 24, 2012
              • 0 Attachment

                Hi all,

                 

                I have uploaded a respective update of BI-041 to the Twiki. This is addressing issues brought up in the teleconference, and in this email thread.

                 

                http://bacnetit.cimetrics.com/pub/BACnetIT/Meetings/BI-041-4.docx

                 

                Best Regards,

                Bernhard

                 

                Bernhard Isler
                Siemens Switzerland Ltd
                Building Technologies Division

                From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Carl Neilson
                Sent: Friday, October 19, 2012 8:46 PM
                To: bacnet-it-wg@yahoogroups.com
                Subject: [bacnet-it-wg] RE: Integration of multiple BINs

                 




                What I take from the statements below (from previous emails) is:

                An NTB device that participates in multiple BINs cannot arbitrarily map all of its objects into all BINs. The simple view of a device that has a single database of objects and each of those objects existing in all BINs in which the device participates does not work. At least not in cases where the objects have cross-device references.

                This implication is that devices which contain such objects are required to maintain separate object spaces (a schedule object cannot exist in multiple BINs if it contains any cross device references). All of the non-reference data can be mapped across BINs (the schedule data can exist in each BIN, but the List_Of_Object_Property_References cannot in the general case).

                The three main use cases that I see, are event notification / logging, scheduling and structured views.

                Scheduling - I think that the scheduling case is simple to solve and it could be solved in a standard way (maintain a List_Of_Object_Property_References per BIN, and from the NTB point of view there are either multiple lists or a conglomerate).

                Structured View - This case is probably simple to solve as well. Any view that crosses BINs is essentially outside the scope of any given BIN and probably should not be mapped into a BIN (the SV object would not exist in any BIN, only in NTB space).

                Event Notification / Logging – not sure.

                 

                The other cases seem to be things that would naturally be contained within a single BIN.

                 

                Object Types that can safely exist in multiple BINs:

                Accumulator

                Analog Input

                Analog Output

                Analog Value

                Binary Input

                Binary Output

                Binary Value

                Calendar

                File

                Group

                Loop

                Multistate Input

                Multistate Output

                Multistate Value

                Program

                Pulse Converter

                Load Control

                Credential Data Input

                CharacterString Value

                DateTime Value

                Large Analog Value

                BitString Value

                OctetString Value

                Time Value

                Integer Value

                Positive Integer Value

                Date Value

                DateTime Pattern Value

                Time Pattern Value

                Date Pattern Value

                Network Security

                Alert Enrollment

                Lighting Command

                 

                Object Types that are able to contain direct cross device references:

                Averaging (Object_Property_Reference)

                Command (Action_List)

                Device (Device_Address_Binding, Time_Synchronization_Recipients, UTC_Time_Synchronization_Recipients, Active_COV_Subscriptions, Manual_Slave_Address_Binding, Slave_Address_Binding, Restart_Notification_Recipients)

                Event Enrollment (Object_Property_Reference, EventParameters.Command_Failure.Feedback_Property_Reference, EventParameters.Floating_Limit.Setpoint_Reference, EventParameters.Change_Of_Life_Safety.Mode_Property_Reference, EventParameters.Extended.Reference, EventParameters.Access_Event.Access_Event_Time_Reference)

                Life Safety Point (Member_Of)

                Life Safety Zone (Zone_Members, Member_Of)

                Notification Class (Recipient_List)

                Schedule (List_Of_Object_Property_References)

                Trend Log (Log_DeviceObjectProperty,

                Access Door (Door Members)

                Structured View (Subordinate_List)

                Trend Log Multiple (Log_DeviceObjectProperty)

                Access Point (Access_Event_Credential, Access_Doors, Zone_To, Zone_From)

                Access Zone (Credentials_In_Zone, Last_Credential_Added, Last_Credential_Removed, Entry_Points, Exit_Points)

                Access User (Members, Member_Of, Credentials)

                Access Rights (Accompaniment)

                Access Credential (Belongs_To, Last_Access_Point)

                Notification Forwarder (Subscribed_Recipients)

                Channel (List_Of_Object_Property_References)

                 

                Object Type that are able to contain indirect/obscured cross device references (* == direct cross device references)

                Event Log (Log_Buffer)

                Global Group (Group_Members*, Present_Value, COVU_Recipients*)

                Carl


                This seems to require that data sources be included (where did the data originally come from). Any data that was not fixed up would not be able to be accurately transferred to a different BIN. The questions for me are:

                                Where does this problem occur?

                          ;       In how many different use cases do we expect it to occur?

                                What problems are expected if the data is transferred without being fixed up?

                                Can non-fixed up data be dropped in a manner that would not break implementations?

                [BI] I will go and address these questions in BI-041. I will go from:

                -           It is not a use case that data is exchanged between two BINs that are both connected to NTB. This should be excluded, it did not work before as well.

                -          Data from one BIN is invalid in another BIN, in particular IDs and references using such IDs.

                -          Data exchang e between BINs need an application level mirror that is aware of how to mangle data for the target context.

                What I am planning to do:

                -          Narrow and enumerate the places where the problem may occur

                -          Enumerate the use cases, and propose a triage among those th at apply and those that we should exclude

                -          Enumerate problems, requirements, behavior etc. when data is exchanged.

                Any help in this would be appreciated, e.g. in enumerating use cases and problems that are in mind.   

                 

                 

                 

                Carl

                 

                 

                From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Isler, Bernhard
                Sent: Thursday, October 18, 2012 1:01 AM
                To: bacnet-it-wg@yahoogroups.com
                Subject: [bacnet-it-wg] Integration of multiple BINs

                 

                 

                Hi all,

                 

                Back to the teleconference discussion we had on Tuesday, it became obvious that:

                 

                -          The requirement for being capable of integrating multiple BINs implies a larger increase in complexity. This includes:

                -          Introduction of some additional identification, for dealing with colliding Device IDs.

                -  &n bsp;       This additional identification has to be incorporated into the data model, mainly in references.

                -          This means that the data model is modified.

                -&nbs p;         Proxied NTB Devices require BIN specific Device IDs, so that an NTB Device can always participate in multiple BINs.

                -          For this, appropriate proxying between legacy BACnet and NTB is comple x.

                -          In particular for setting references, for reading references, and mapping of Device object Object_Identifier on the far side of the proxy.

                 

                Do we really want to pursue this requirement?

                 

                Best,

                Bernhard

                 

                Bernhar d Isler
                Siemens Switzerland Ltd
                Building Technologies Division
                IC BT CPS GDT AS
                Gubelstrasse 22
                CH-6301 Zug, Switzerland

                Tel: +41 (41) 724 33 87
                Mob: +41 (79) 561 77 23
                Fax: +41 (41) 723 48 94

                mailto:bernhard.isler@...
                http://www.siemens.com/buildingtechnologies

                Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

                &nbs p;




                 




              • James F. Butler
                Dear IT-WG members, As most of you know, the IT-WG meeting in Atlanta will start at 1:30 p.m. on Tuesday, and we have four hours. Our primary agenda item is
                Message 7 of 10 , Nov 2, 2012
                • 0 Attachment

                  Dear IT-WG members,

                   

                  As most of you know, the IT-WG meeting in Atlanta will start at 1:30 p.m. on Tuesday, and we have four hours.  Our primary agenda item is to continue the discussion of BI-041.  Bernhard published an updated document last week (see below); please read it and review the recent e-mail traffic prior to the meeting.

                   

                  I also encourage you to attend the TBA session that begins at 1:30 p.m. on Monday, in which we will have a discussion about the future of BACnet.  The outcome of that discussion is likely to affect the direction of the IT-WG.

                   

                  See you in Atlanta .

                   

                  - Jim Butler

                    BACnet IT-WG convener

                   


                  From: bacnet-it-wg@yahoogroups.com [mailto: bacnet-it-wg@yahoogroups.com ] On Behalf Of Isler, Bernhard
                  Sent: Wednesday, October 24, 2012 4:02 PM
                  To: bacnet-it-wg@yahoogroups.com
                  Subject: [bacnet-it-wg] RE: Integration of multiple BINs

                   




                  Hi all,

                   

                  I have uploaded a respective update of BI-041 to the Twiki. This is addressing issues brought up in the teleconference, and in this email thread.

                   

                  http://bacnetit.cimetrics.com/pub/BACnetIT/Meetings/BI-041-4.docx

                   

                  Best Regards,

                  Bernhard

                   

                  Bernhard Isler
                  Siemens Switzerland Ltd
                  Building Technologies Division

                   

                • James F. Butler
                  Dear IT-WG members, We had a productive discussion of BI-041-4 in Atlanta. Our next F2F meeting will be in Dallas during the ASHRAE winter meeting in late
                  Message 8 of 10 , Nov 28, 2012
                  • 0 Attachment
                    Dear IT-WG members,
                     
                    We had a productive discussion of BI-041-4 in Atlanta.  Our next F2F meeting will be in Dallas during the ASHRAE winter meeting in late January.
                    Bernhard plans to do another revision of BI-041 prior to our meeting in Dallas. We request your comments on BI-041-4; please read it and respond as soon as possible so that your feedback will be taken into consideration for the next revision.  You may download the document from:
                     
                     
                    Thanks,
                     
                    - Jim Butler
                      BACnet IT-WG convener
                     
                     
                  Your message has been successfully submitted and would be delivered to recipients shortly.