FOREWORD. In addition, changes to BTL Specified Tests might also contain a yellow highlight to indicate the changes made by this addendum.

Transcription

1 [This foreword and the Overview on the following pages are not part of this Test Package. They are merely informative and do not contain requirements necessary for conformance to the Test Package.] FOREWORD The purpose of this addendum is to present current changes being made to the BTL Test Package. These modifications are the result of change proposals made pursuant to the continuous maintenance procedures and of deliberations within the BTL- WG Committee. The changes are summarized below. BTL-TP12.1b-1: Repeat for all data types, pg 2. [wid0658] BTL-TP12.1b-2: COVU-B Testing, pg 3. [wid0695] BTL-TP12.1b-3: Segmentation Supported Testing, pg 5. [wid0710] BTL-TP12.1b-4: AE-INFO-B Conditionality Changes, pg 8. [wid0540] BTL-TP12.1b-5: Event Logging Size, pg 9. [wid0546] BTL-TP12.1b-6: Removal of Directive for Command Prioritization Test, pg 10. [wid0590] BTL-TP12.1b-7: ReinitializeDevice Requirement Changes, pg 11. [wid0619] BTL-TP12.1b-8: Routing Checklist Change, pg 14. [wid0694] BTL-TP12.1b-9: DM-OCD-A clarifications, pg 15. [wid0714] BTL-TP12.1b-10: Correct Reference in DM-DCC-B, pg 16. [wid0718] BTL-TP12.1b-11: Synchronize required data types in scheduling BIBBs, pg 17. [wid0720] BTL-TP12.1b-12: Add CHANGE_OF_STATUS_FLAGS and CHANGE_OF_RELIABILITY, pg 18. [wid0724] In the following document, language to be added to existing clauses within the BTL Test Package 12.1 is indicated through the use of italics, while deletions are indicated by strikethrough. Where entirely new subclauses are proposed to be added, plain type is used throughout. In addition, changes to BTL Specified Tests might also contain a yellow highlight to indicate the changes made by this addendum. When this addendum is applied, all highlighting will be removed. Change markings on tests will remain to indicate the difference between the new test and an existing test. If a test being modified has never existed in 135.1, the applied result should not contain any change markings. When this is the case, square brackets will be used to describe the changes required for this test. Each addendum can stand independently unless specifically noted via dependency within the addendum. If multiple addenda change the same test or section, each future released addendum that changes the same test or section will note in square brackets whether or not those changes are reflected. This addendum contains results of various clarification requests put forth to the BTL-WG that resulted in test package changes. 1

2 BTL 12.1b-1: Repeat for all data types This document makes changes to the regarding tests BTL and BTL , to ensure that the test steps are repeated for all supported datatypes. The test standard states, in the preamble for these two Averaging tests: The datatype of the sampled property can be BOOLEAN, INTEGER, Unsigned, Enumerated, or Real. The tests in this clause shall be repeated once for each of these datatypes. But that repetition is not currently noted in the tests themselves, nor in the Test Plan. [In BTL Test Plan, add a Test Directive to each test in section 3.4.1] Base Requirements The IUT initiates any confirmed requests. BTL Reinitializing the Samples Repeat for each datatype that the IUT supports in an Averaging object. BTL Managing the Sample Window Repeat for each datatype that the IUT supports in an Averaging object. [In BTL Specified Tests, add section header and this preamble, before tests and already derived from ] Averaging Object Tests An Averaging object provides a way to monitor the average, minimum, and maximum values attained by a sampled property. The datatype of the sampled property can be BOOLEAN, INTEGER, Unsigned, Enumerated, or Real. The tests in this clause shall be repeated once for each of these datatypes. 2

3 BTL 12.1b-2: COVU-B Testing This document adds testing for BIBB DS-COVU-B: Specification of unsubscribed UnconfirmedCOVNotifications has been in clauses 13.7 and since Protocol_Revision 2. Testing for this was never specified in any SSPC proposal. Testing is added here for that. Addendum b specified a standardized usage of this mechanism for Device in the production of Restart notifications. Test exists for that, so no changes are needed here for that [In BTL Specified Tests, add new test] 8.3.X11 Unsubscribed COV Service Initiation Test Reason for Change: This test is not specified in any SSPC proposal. Purpose: To verify that the IUT initiates UnconfirmedCOVNotification service requests. Test Concept: Configure one or more objects in IUT to produce unsubscribed UnconfirmedCOVNotifications. Test Steps: 1. MAKE (the IUT issue an unsubscribed UnconfirmedCOVNotification) 2. BEFORE Notification Fail Time RECEIVE UnconfirmedCOVNotification-Request, DESTINATION = (any valid address), 'Subscriber Process Identifier' = 0, 'Initiating Device Identifier' = IUT, 'Monitored Object Identifier' = (any object present in IUT), 'Time Remaining' = 0, 'List of Values' = (any valid set of values) [In BTL Test Plan, add new section COV Unsubscribed - B] 4.17 Data Sharing - COV Unsubscribed - B Base Requirements Base requirements must be met by any IUT claiming conformance to this BIBB. BTL X11 - Unsubscribed COV Service Initiation Test Test Method Manual [In BTL Checklist, add new section as shown here] 4 Data Sharing Support Listing Option... 3

4 Support Listing Option Data Sharing - COV Unsubscribed - B R Base Requirements 4

5 BTL 12.1b-3: Segmentation Supported Testing If a request has the segmented-response-accepted bit set, and/or if a device has the Segmentation _Supported property, these can be tested. [In BTL Specified Tests, add new tests, as shown here] X2 Max_Segments_Accepted at least the minimum There is no SSPC proposal for this change. Purpose: To verify that the IUT implements the Max_Segments_Accepted property value when it does support segmentation. Configuration Requirements: If the IUT cannot be configured to support segmentation, then this test shall be skipped. Test Steps: 1. VERIFY (Max_Segments_Accepted > 1) X3 Respects max-segments-accepted bit pattern There is no SSPC proposal for this change. Purpose: To verify that the IUT abides by the 'max-segments-accepted' parameter, when the size of the response does require segmentation. Configuration Requirements: Use a very small 50 octet 'max-apdu-length-accepted' size in the request. The BACnet- Confirmed-Request-PDU shall be one where the response size will exceed 2 times 'max-apdu-length-accepted' and so require at least three segments. If the largest response that the IUT can return is 100 or fewer octets, then this test shall be skipped. Test Steps: 1. TRANSMIT BACnet-Confirmed-Request-PDU, 'segmented-response-accepted' = TRUE 'max-segments-accepted' = 2 2. RECEIVE BACnet-Abort-PDU, Abort Reason = BUFFER_OVERFLOW Hints to Tester: An attempt to read the whole Object_List might suffice. Or a ReadRange or ReadPropertyMultiple or AtomicReadFile request, if any of those services are executed. 13.X12.1 Reading with maximum-segments-accepted bit pattern B'000' There is no SSPC proposal for this change. Purpose: To verify that the IUT implements at least support for two segments, when the 'max-segments-accepted' parameter that it sends is B 000. Configuration Requirements: If the IUT cannot be configured to issue any BACnet-Confirmed-Request-PDU with 'segmented-response-accepted' = TRUE and the 'max-segments-accepted' parameter equal to B 000, then this test shall be skipped. 1. RECEIVE BACnet-Confirmed-Request-PDU, 'segmented-response-accepted' = TRUE 'max-segments-accepted' = B TRANSMIT BACnet-ComplexACK-PDU, 'segmented-message' = TRUE, 'more-follows' = TRUE, 'sequence-number' = 0, 5

6 'proposed-window-size' = (any valid value) 3. RECEIVE BACnet-SegmentACK-PDU, server = FALSE, negativeack = FALSE 4. TRANSMIT BACnet-ComplexACK-PDU, 'segmented-message' = TRUE, 'more-follows' = FALSE, 'sequence-number' = 1 5. RECEIVE BACnet-SegmentACK-PDU, server = FALSE, negativeack = FALSE [In BTL Test Plan, add new sections and test references, as shown here] 2.2 Segmentation Support Base Requirements All BACnet devices must meet these base requirements. BTL X2 - Max_Segments_Accepted at least the minimum Test Method Manual Test Conditionality If the Segmentation_Supported property of Device object cannot be made to hold a value other than NO-SEGMENTATION, then this test shall be skipped Issues Segmented Responses BACnet devices which are capable of issuing segmented responses shall meet these requirements. BTL X3 - Respects max-segments-accepted bit pattern Test Method Manual Test Conditionality Must be executed, if there is any response generated by IUT which is large enough to require segmentation. Test with a 'max-segments-accepted' bit pattern value that is less than TD s Max_Segments_Accepted property value, to ascertain that the 'max-segments-accepted' bit pattern value is what governs Accepts Segmented Responses without Specifying the Maximum BACnet devices which accept segmented responses shall meet these requirements. BTL - 13.X Reading with maximum-segments-accepted bit pattern B'000' Test Method Manual Test Conditionality If the IUT cannot be configured to issue any BACnet-Confirmed- Request-PDU with 'segmented-response-accepted' = TRUE and the 'max-segments-accepted' parameter equal to B 000, then this test shall be skipped. 6

7 [In BTL Checklist, add new section as shown here] 2.0 Basic BACnet Functionality Support Listing Option Basic Functionality (applies to all BACnet devices) X R Base Requirements X R EPICS Consistency Tests X R Supports DS-RP-B C 1 Uses Who-Is and I-Am services for router address discovery C 1 Uses Who-Is-Router-to-Network (any network) for router address discovery C 1 Uses Who-Is-Router-to-Network (specific network) for router address discovery C 1 Uses MAC broadcasts for router discovery N Uses static router address configuration BTL-C 2 Supports DM-DDB-B C 2, 3 Supports DM-DOB-B O Initiates Confirmed Requests 1 At least one of these options must be supported if the device is capable of transmitting any unicast service requests besides COV notifications, including unicast service requests containing remote or global broadcasts. 2 Required unless the device is an MS/TP slave device. 3 Required if the device implements protocol revision 5 or higher. Segmentation Support R Base Requirements O Issues Segmented Responses O Accepts Segmented Responses without Specifying the Maximum 7

8 BTL 12.1b-4: AE-INFO-B Conditionality Changes The testing for proper behavior of AE-INFO-B, as currently expressed in Test Package assumes that some object can be caused to enter an Event_State other than NORMAL, which is not always the case. [In BTL Test Plan, revise existing conditionality] Event Information with one Active Event Test Conditionality Must be executed. If the IUT cannot be configured to contain any object with an active event, then this test shall be skipped Event Information Based on Event_State Test Conditionality Must be executed. If the IUT cannot be configured to contain any object with an active event, then this test shall be skipped Event Information based on Acknowledged_Transitions Test Conditionality Must be executed. If the IUT cannot be configured to contain any object with an unacknowledged event, then this test shall be skipped. 8

9 BTL 12.1b-5: Event Logging Size BTL-CR-0333 rules that The SSPC will be asked to clarify the correct behavior. In the meantime, the Test Plan will only TRANSMIT EventNotifications in test X2 of a size that the IUT is capable of logging. Test X1, the device shall be capable of logging anything that it emits, so that test does need any added Test Directive. [In BTL Test Plan, add Test Directive to existing tests X2 and X4] BTL X2 - Remote Logging of Notifications REPEAT for both Confirmed and UnconfirmedEventNotifications. REPEAT for events which contain the optional message text parameter and for those which don't. REPEAT for all BACnetEventTypes up to the Protocol_Revision claimed by the IUT. TRANSMIT EventNotifications of a size that the IUT is capable of logging. This does include CHANGE_OF_LIFE_SAFETY, BUFFER_READY, and complex event types. BTL X4 - Remote ACK_NOTIFICATION Logging TRANSMIT EventNotifications of a size that the IUT is capable of logging. 9

10 BTL 12.1b-6: Removal of Directive for Command Prioritization Test The Command Prioritization test itself is not restricting the priorities. In Test Plan we will delete the Test Directive of test in Analog Output, as that information belongs in the Configuration Requirements: section of the test itself, if it is appropriate to have it at all. [In BTL Test Plan, modify to delete the Test Directive of test in Analog Output, as follows] Supports Command Prioritization The objects contain a priority array and support command prioritization. BTL Command Prioritization Test Test Method Manual All priorities must be supported by the IUT. The lab must be able to command at priorities that are greater than, that are less than, and that are equal to 8; not just at a single priority. 10

11 BTL 12.1b-7: ReinitializeDevice Requirement Changes The ReinitializeDevice service doesn t always have same password requirement for all parameters. Note Device Management - Backup and Restore - B already specifies behavior for Backup and Restore separately. [In BTL Checklist, in the Device Management - ReinitializeDevice - B section, add new line items for password requirement for each parameter separately.] Device Management - Reinitialize Device - B R Base Requirements C 1 Implements ReinitializeDevice WARMSTART with a password C 1 Implements ReinitializeDevice WARMSTART with no password C 1 Implements ReinitializeDevice COLDSTART with a password C 1 Implements ReinitializeDevice COLDSTART with no password 1 At least one of these options is required in order to claim conformance to this BIBB. [In BTL Test Plan, modify sections as described below] Implements ReinitializeDevice WARMSTART with a Password The IUT can deny, or can be made to deny, a ReinitializeDevice WARMSTART service request that does not contain a valid password COLDSTART with a Correct Password WARMSTART with a Correct Password BTL COLDSTART with Missing or Invalid Password BTL WARMSTART with Missing or Invalid Password 11

12 Implements ReinitializeDevice WARMSTART with no Password The IUT accepts, or can be made to accept, a ReinitializeDevice WARMSTART service request that does not contain a valid password i COLDSTART with no Password i WARMSTART with no Password Implements ReinitializeDevice COLDSTART with a Password The IUT can deny, or can be made to deny, a ReinitializeDevice COLDSTART service request that does not contain a valid password COLDSTART with a Correct Password Test Method Manual WARMSTART with a Correct Password BTL COLDSTART with Missing or Invalid Password Test Method Manual 12

13 BTL WARMSTART with Missing or Invalid Password Implements ReinitializeDevice COLDSTART with no Password The IUT accepts, or can be made to accept, a ReinitializeDevice COLDSTART service request that does not contain a valid password i COLDSTART with no Password Test Method Manual i WARMSTART with no Password 13

14 BTL 12.1b-8: Routing Checklist Changes Under Routing BIBB currently in the Functionality Checklist, we needed some clarity as to what options are required and when. [In BTL Checklist, revise the existing Routing section] Support Listing Option Routing R O 1 O 1 Base Requirements Routes packets between physical BACnet LANs Routes packets between a physical LAN and one or more virtual LANs 1 One or more of these options is required in order to claim in this section. 14

15 BTL 12.1b-9: DM-OCD-A Clarifications The footnote in DM-OCD-A needed some clarification. [In BTL Checklist, in Device Management - Object Creation and Deletion - A, modify footnote 1]... Device Management - Object Creation and Deletion - A R Base Requirements BTL-R Can create objects using Object_Identifier with no initial values S 1 Can create objects using Object_Type with no initial values S Can create objects by Object_Identifier with initial values which includes Object_Name S 1 Can create objects by Object_Type with initial values which includes Object_Name C 2 Can create and delete Accumulator objects C 2 Can create and delete Analog Input objects C 2 Can create and delete... objects 1 For each object type where thethe IUT may only supports creation with the CreateObject service, the Object_Type form of CreateObject for the object types which, the Object_Identifier form of CreateObject shall beis also supported. 2 At least one of these is required in order to claim conformance to this BIBB. 3 IUT should not claim this functionality if the only method of creating a File object is by initiating the device restore procedure. 15

16 BTL 12.1b-10: Correct Reference in DM-DCC-B The test referenced in DM-DCC-B 'supports receiving a DeviceCommunicationControll Service request with a password' was incorrect. [In BTL Test Plan, change test reference as indicated] Supports Receiving a DeviceCommunicationControl Service Request with a Password The IUT requires, or can be made to require, a valid password parameter in a DeviceCommunicationControl service request Invalid Password BTL Missing Password Configuration As per ASHRAE BTL Specified Tests. [In BTL Specified Test, remove test Missing Password] 16

17 BTL 12.1b-11: Synchronize required data types in scheduling BIBBs The standard in K.3.3 BIBB - Scheduling - External-B in states: The B device provides date and time scheduling of the values of specific properties of specific objects in other devices. Devices claiming conformance to SCHED-E-B shall also support SCHED-I-B and DS-WP-A. The List_Of_Object_Property_References property shall support references to objects in external devices and be writable. and BTL has represented that requirement with BTL-R Is able to schedule NULL values BTL-R Is able to schedule BOOLEAN values BTL-R Is able to schedule Unsigned values BTL-R Is able to schedule REAL values BTL-R Is able to schedule Enumerated values The standard in K.3.5 BIBB - Scheduling - Advanced View and Modify - A in states: Devices claiming support for this BIBB shall be capable of creating, deleting, presenting, and modifying Schedule objects that schedule any of the following types: REAL, ENUMERATED, Unsigned32 and which may contain NULL values and shall be capable of changing the datatype that a Schedule object schedules. This discrepancy seems to be an interoperability problem and therefore the BTL will update the checklist such that the SCHED-VM-A will support the datatypes which are requirements of SCHED-E-B. [In BTL Checklist, Scheduling - View Modify - A section, revise the Conformance Code on BOOLEAN to BTL-R.] Scheduling - View Modify - A R Base Requirements R Supports DS-RP-A R Supports DS-WP-A R Is able to schedule any B-side device regardless of the claimed Protocol_Revision in the B- side device. R Is able to present and modify schedules that do not include the Exception_Schedule property R Is able to present and modify a Calendar Object R Is able to present and modify schedules of Enumerated type R Is able to present and modify schedules of REAL type R Is able to present and modify schedules of Unsigned32 type OBTL-R Is able to present and modify schedules of BOOLEAN type O Is able to present and modify schedules of INTEGER (signed) type O Is able to present and modify schedules of Double type O Is able to present and modify schedules of Octet String type 17

18 BTL 12.1b-12: Add CHANGE_OF_STATUS_FLAGS and CHANGE_OF_RELIABILITY At Protocol_Revision 11 another new format: the CHANGE_OF_STATUS_FLAGS notification was added. At Protocol_Revision 13 another new format: the CHANGE_OF_RELIABILITY notification was added. The behavior of executing these should be required in AE-N-A. [In BTL Test Plan, add two new sections after existing section, as indicated] 5.1 Alarm and Event - Notification - A Processes CHANGE_OF_STATUS_FLAGS Notifications The IUT is capable of executing event notifications that convey a CHANGE_OF_STATUS_FLAGS event transition ConfirmedEventNotification Using the Time Form of the 'Timestamp' Parameter and Conveying a Text Message, ConfirmedEventNotification Using the DateTime Form of the 'Timestamp' Parameter and no Text Message, or ConfirmedEventNotification Using the Sequence Number Form of the 'Timestamp' Parameter and no Text Message Test Conditionality Must be executed. At least one of the tests must be executed with the Event Type set to CHANGE_OF_STATUS_FLAGS Processes CHANGE_OF_RELIABILITY Notifications The IUT is capable of executing event notifications that convey a CHANGE_OF_ RELIABILITY event transition ConfirmedEventNotification Using the Time Form of the 'Timestamp' Parameter and Conveying a Text Message, ConfirmedEventNotification Using the DateTime Form of the 'Timestamp' Parameter and no Text Message, or ConfirmedEventNotification Using the Sequence Number Form of the 'Timestamp' Parameter and no Text Message Test Conditionality Must be executed. At least one of the tests must be executed with the Event Type set to CHANGE_OF_RELIABILITY. [In BTL Checklist, in Alarm and Event - Notification - A, add two new lineitems at end as indicated.] Alarm and Event - Notification - A R Base Requirements R Processes CHANGE_OF_STATUS_FLAGS notifications R Processes CHANGE_OF_RELIABILITY notifications 18