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.0g-1: Update Backup and Restore Tests, pg 2. [wid0443, BTL-CR-0277, BTL-CR-0287, BTL-CR-0332] BTL-TP12.0g-2: Update Averaging Object Tests, pg 12. [wid0462, BTL-CR-0309] BTL-TP12.0g-3: Clarify AE-INFO-B Requirements, pg 15. [wid0463] BTL-TP12.0g-4: Modify Network Tests to handle Unicast I-Ams, pg 16. [wid0192, wid0464, BTL-CR-0248] BTL-TP12.0g-5: Update Password Handling Tests, pg 26. [wid0471] BTL-TP12.0g-6: Clarify Initiates Confirmed Requests, pg 32. [wid0473] BTL-TP12.0g-7: Clarify use of Deprecated BIBBs, DM-UTC-A and DM-TS-A, pg 33. [wid0477, BTL-CR-0293] BTL-TP12.0g-8: Clarify use of Deprecated BIBBs, pg 34. [wid0484, BTL-CR-0293] BTL-TP12.0g-9: Clarified Event_Message_Texts Tests, pg 36. [wid0486, BTL-CR-319] BTL-TP12.0g-10: Remove COV Subscription Failure Test, pg 37. [wid0488, BTL-CR-323] BTL-TP12.0g-11: Adds Global Group List Property to Test Plan, pg 38. [wid0499] BTL-TP12.0g-12: Improve Event_Enable Test, pg 41. [wid0510, BTL-CR-0196] In the following document, language to be added to existing clauses within the BTL Test Package 12.0 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-TP 12.0g-1: Update Backup and Restore Tests Overview: The following changes were noted and changed regarding the Backup and Restore client tests: References in the Test Plan-12.0 are to addendum m and tests numbered 13.X., but the addendum was entitled m and the tests were numbered at ratification. An errata changed BTL-CR-0287 called for the test to be modified. BTL-CR-0332 called for the test to be modified. The use of > instead of in is an errata. A Note is added to test to clarify the rationale for the Protocol_Revision restriction. Changes: [In BTL Test Plan, modify as follows in section 8.17] 8.17 Device Management - Backup and Restore - A Base Requirements Base requirements must be met by any IUT claiming conformance to this BIBB m-4BTL - 13.X Initiate a Full Backup and Restore Configuration As per ASHRAE BTL Specified Tests. Test Conditionality This test should be repeated in order to cover all of the TD characteristics listed in the definition of the test m X Can Abort Backup if Error Received from TD Configuration As per ASHRAE m X Can Abort Restore if Error Received from TD Configuration As per ASHRAE Supports User Initiated Abort Backup The IUT supports a user initiated abort of the backup procedure m X Initiate an Abort Backup 2

3 Configuration As per ASHRAE Supports User Initiated Abort Restore The IUT supports the user initiating an abort of the restore procedure m X Initiate an Abort Restore Configuration As per ASHRAE Device Management - Backup and Restore - B Base Requirements Base requirements must be met by any IUT claiming conformance to this BIBB m-4BTL X Execution of Full Backup and Restore Procedure Configuration As per ASHRAE BTL Specified Tests m X Attempting Backup While Already Performing a Backup Procedure Configuration As per ASHRAE m X Attempting Backup While Already Performing a Restore Procedure Configuration As per ASHRAE

4 m X Attempting Restore While Already Performing a Backup Procedure Configuration As per ASHRAE m X Attempting Restore While Already Performing a Restore Procedure Configuration As per ASHRAE m-4BTL X Ending Backup and Restore Procedures via Timeout Configuration As per ASHRAE BTL Specified Tests m X Ending Backup and Restore Procedures via Abort Configuration As per ASHRAE Supports Password Protected Backup The IUT denies, or can be made to deny, a ReinitializeDevice <STARTBACKUP > service request that does not contain a valid password m X Attempting Backup with an Invalid Password Configuration As per ASHRAE Supports Non-Password Protected Backup The IUT does not require, or can be made to not require, a password for a ReinitializeDevice <STARTBACKUP> service request. 4

5 m X Executing and Ending a Backup Procedure when a password is not required Configuration As per ASHRAE Supports Password Protected Restore The IUT denies, or can be made to deny, a ReinitializeDevice <STARTRESTORE > service request that does not contain a valid password m X Attempting Restore with an Invalid Password Configuration As per ASHRAE Supports Non-Password Protected Restore The IUT does not require, or can be made to not require, a password for a ReinitializeDevice <STARTRESTORE> service request m-4BTL X Executing and Ending a Restore Procedure when a Password is not Required Configuration As per ASHRAE BTL Specified Tests Changes Operational Behavior during a Backup Procedure The IUT changes its operational behavior during a Backup Procedure m X System_Status during a Backup Procedure Configuration As per ASHRAE Changes Operational Behavior during a Restore Procedure The IUT changes its operational behavior during a Restore Procedure m X System_Status during a Restore Procedure 5

6 Configuration As per ASHRAE [In BTL Specified Tests, add tests derived from m-4] Execution of Full Backup and Restore Procedure Purpose: This test case verifies that the IUT can execute a full Backup and Restore procedure. Test Concept: This test takes the IUT through a successful Backup and then a successful Restore procedure. The Database_Revision and Last_Restore_Time properties are noted before the procedure begins for later comparison. The IUT is then commanded to enter the Backup state; all the files are read, and the IUT is commanded to end the backup. If the Database_Revision property can be changed by means other than the restore procedure, it is modified and checked to ensure that it incremented correctly; then the IUT is commanded to enter the Restore state. If the file objects do not exist on the IUT, the TD will create them in the IUT. The files are then truncated to size 0, the file contents are written to the IUT, and the IUT is commanded to end the restore. The Database_Revision and Last_Restore_Time properties are checked to ensure that they incremented or advanced correctly. For IUTs that use Stream Access when performing the AtomicReadFile and AtomicWriteFile services, a Maximum Requested Octet Count (MROC) and a Maximum Write Data Length (MWDL) shall be calculated before starting the test. These values shall be used during the test. MROC shall be 16 less than the minimum of the TD s Max_APDU_Length_Accepted and the IUT s maximum transmittable APDU length. MWDL shall be 21 less than the minimum of the TD s maximum transmittable APDU length and the IUT s Max_APDU_Length_Accepted. 1. READ DR1 = Database_Revision 2. READ LRT1 = Last_Restore_Time 3. READ OL1 = Object_List 4. REPEAT X = (1 through length of OL1) DO { READ NAMES[X] = (OL1[X]), Object_Name } 5. IF (Protocol_Revision is present and Protocol_Revision 10) THEN READ BPT = Backup_Preparation_Time READ RPT = Restore_Preparation_Time READ RCT = Restore_Completion_Time VERIFY Backup_And_Restore_State = IDLE 6. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = STARTBACKUP, Password = (any valid password) 7. RECEIVE BACnet-Simple-ACK-PDU 8. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT BPT READ BRSTATE = Backup_And_Restore_State READ CF = Configuration_Files WHILE (BRSTATE = PREPARING_FOR_BACKUP) DO { WAIT 1 second READ BRSTATE = Backup_And_Restore_State IF CF is an empty list THEN READ CF = Configuration_Files IF CF is a non-empty list THEN READ X = (the file referenced by Configuration_Files[1]).Name } CHECK (BRSTATE = PERFORMING_A_BACKUP) 6

7 9. READ CF = Configuration_Files 10. CHECK (CF is a non-empty array of BACnetObjectIdentifiers referring to File objects) 11. REPEAT X = (each entry in CF) DO { READ Y = X, File_Access_Method IF (Y = RECORD_ACCESS) WHILE (the last read resulted in an Ack with 'End Of File' == FALSE) DO { TRANSMIT AtomicReadFile-Request, Object Identifier = X, File Start Record = (the next unread record), Requested Record Count = 1 RECEIVE AtomicReadFile-ACK, 'End Of File' = TRUE FALSE, File Start Record = Z, Requested Record Count = 1 Returned Data = (File contents) Error-PDU -- only acceptable for the first record and only when there are no records in the file 'Error Class' = SERVICES, 'Error Code' = INVALID_FILE_START_POSITION } WHILE (the last read did not indicate 'End Of File') DO { TRANSMIT AtomicReadFile-Request, Object Identifier = X, File Start Position = (the next unread octet), Requested Octet Count = MROC RECEIVE AtomicReadFile-ACK, 'End Of File' = TRUE FALSE, File Start Position = (the next unread octet) File Data = (File contents of length MROC if 'End Of File' is FALSE or of length MROC or less if 'End Of File' is TRUE) Error-PDU -- only acceptable for the first record and only when there are no records in the file 'Error Class' = SERVICES, 'Error Code' = INVALID_FILE_START_POSITION } } 12. TRANSMIT ReinitializeDevice-Request, Reinitialize State Of Device = ENDBACKUP, Password = (any valid password) 13. RECEIVE BACnet-Simple-ACK-PDU 14. VERIFY System_Status! = BACKUP_IN_PROGRESS 15. IF (Protocol_Revision is present and Protocol_Revision 10) THEN VERIFY Backup_And_Restore_State = IDLE 16. IF (Database_Revision is changeable) THEN MAKE (the configuration in the IUT different, such that the Database_Revision property increments) VERIFY Database_Revision <> DR1 READ DR2 = Database_Revision CHECK (DR1 <> DR2) 17. TRANSMIT ReinitializeDevice-Request, Reinitialize State Of Device = STARTRESTORE, Password = (any valid password) 18. RECEIVE BACnet-Simple-ACK-PDU 19. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RPT READ BRSTATE = Backup_And_Restore_State WHILE (BRSTATE = PREPARING_FOR_RESTORE) DO { WAIT 1 second READ BRSTATE = Backup_And_Restore_State } CHECK (BRSTATE = PERFORMING_A_RESTORE) 20. READ OL2 = Object_List 7

8 21. REPEAT X = (entry in CF) DO { IF (X is not in OL2) TRANSMIT CreateObject-Request Object Identifier = X RECEIVE CreateObject-ACK Object Identifier = X READ FS = X, File_Size IF (File_Size is not equal to the size of the backed up file) WRITE X, File_Size = 0 IF (Y = RECORD_ACCESS) TRANSMIT AtomicWriteFile-Request File Identifier = X File Start Record = 0 Record Data = (file content for first record obtained in step 11) RECEIVE AtomicWriteFile-ACK File Start Record = 0 REPEAT REC = (each record in the backup of this file) { TRANSMIT AtomicWriteFile-Request File Identifier = X File Start Record = -1 Record Count = 1 Record Data = REC RECEIVE AtomicWriteFile-ACK File Start Record = (the record number) } REPEAT Z = (0 through the file size, in increments of MWDL) DO { TRANSMIT AtomicWriteFile-Request File Identifier = X File Start Position = Z Record Data = (file contents obtained from the backup, the number of octets being the lesser of (file size - Z) and MWDL) RECEIVE AtomicWriteFile-ACK File Start Position = Z } } 22. IF (Protocol_Revision is present and Protocol_Revision 10) THEN VERIFY Backup_And_Restore_State = RESTORE_IN_PROGRESS PERFORMING_A_RESTORE 23. TRANSMIT ReinitializeDevice-Request, Reinitialize State Of Device = ENDRESTORE, Password = (any valid password) 24. RECEIVE BACnet-Simple-ACK-PDU 25. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RCT VERIFY Backup_And_Restore_State = IDLE 26. READ DR3 = Database_Revision 27. CHECK (DR3 <> DR1) 28. IF (Database_Revision was changed in step 16) THEN CHECK (DR3 <> DR2) 29. VERIFY Last_Restore_Time > LRT1 30. READ OL3 = Object_List 31. CHECK (that OL1 and OL3 contain the same set of objects) 32. REPEAT X = (1 through length of OL1) DO { VERIFY (OL1[X]), Object_Name = NAMES[X] } [In BTL Specified Tests, add tests derived from m-4] Ending Backup and Restore Procedures via Timeout 8

9 Purpose: This test case verifies that the IUT will end Backup and Restore procedures after not receiving any messages related to the backup or restore for longer than Backup_Failure_Timeout and that the Backup_Failure_Timeout property is writeable. 1. WRITE Backup_Failure_Timeout = (A value T1 greater than Backup_Preparation_Timeout) 2. VERIFY Backup_Failure_Timeout = T1 3. IF (Protocol_Revision is present and Protocol_Revision 10) THEN READ BPT = Backup_Preparation_Time 4. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = STARTBACKUP, 'Property Identifier' = (any valid password) 5. RECEIVE Simple-ACK-PDU 6. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT BPT READ BRSTATE = Backup_And_Restore_State WHILE (BRSTATE = PREPARING_FOR_BACKUP) DO { WAIT 1 second READ BRSTATE = Backup_And_Restore_State } CHECK (BRSTATE = PERFORMING_A_BACKUP) 7. WAIT (T seconds) 8. IF (Protocol_Revision is present and Protocol_Revision 10) THEN VERIFY Backup_And_Restore_State = IDLE 9. VERIFY System_Status! = BACKUP_IN_PROGRESS 10. IF (Protocol_Revision is present and Protocol_Revision 10) THEN READ RPT = Restore_Preparation_Time READ RCT = Restore_Completion_Time 11. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = STARTRESTORE, Password = (any valid password) 12. RECEIVE BACnet-Simple ACK-PDU 13. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RPT READ BRSTATE = Backup_And_Restore_State WHILE (BRSTATE = PREPARING_FOR_RESTORE) DO { WAIT 1 second READ BRSTATE = Backup_And_Restore_State } CHECK (BRSTATE = PERFORMING_A_RESTORE) WAIT (30 seconds) 14. WAIT (T seconds) 15. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RCT VERIFY Backup_And_Restore_State = IDLE 16. VERIFY System_Status! = DOWNLOAD_IN_PROGRESS Notes to Tester: After an incomplete restore attempt, the IUT may revert to a default configuration or another state that is different from the IUT state when this test was started. [In BTL Specified Tests, add tests derived from m-4] Starting and Ending a Restore Procedure when a Password is not Required Purpose: This test case verifies that the IUT ignores the password. If the IUT cannot be made to accept a ReinitializeDevice service request that contains any or no password, then this test shall be omitted. 9

10 1. IF (Protocol_Revision is present and Protocol_Revision 10) THEN READ RPT = Restore_Preparation_Time READ RCT = Restore_Completion_Time 2. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = STARTRESTORE, Password = (any non-zero length password) 3. RECEIVE BACnet-Simple ACK-PDU 4. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RPT 5. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = ENDABORTRESTORE, Password = (any non-zero length password) 6. RECEIVE BACnet-Simple ACK-PDU 7. IF (Protocol_Revision is present and Protocol_Revision 10) THEN WAIT RCT 8. VERIFY System_Status! = DOWNLOAD_IN_PROGRESS [In BTL Specified Tests, add tests derived from m-4] Initiate a Full Backup and Restore Purpose: To verify that the IUT can perform a Backup and Restore on a BACnet server device. Test Concept: The IUT is first made to initiate a Backup and then a Restore of the TD device. This test verifies that the IUT performs the Backup procedure correctly by comparing the resulting restored file with the original. The TD is made to respond appropriately such that the Backup and Restore procedures are completed normally. The final check can be accomplished using a file compare of the original files to the files restored or by comparing the network traffic during the backup to the network traffic during the restore. The number of files, the order of the files, and the file content should be the same. The test is to be executed multiple times with the TD configured with different sets of backup and restore characteristics. Configuration Requirements: The IUT is configured to already contain a device binding for the TD device. The TD is configured with some of the following characteristics: Backup Characteristics: 1. The TD is configured to contain an APDU size that is smaller than the APDU size of the IUT. If the TD and the IUT support segmentation, the TD is configured to support a smaller window size than the IUT. 2. The TD is configured to contain a configuration file of size zero. 3. The TD is configured to contain some configuration files that are STREAM_ACCESS and some that are RECORD_ACCESS. 4. The TD is configured to only allow access to File and Device objects during the Backup and Restore procedures. All other attempts shall result in an error from the TD. 5. The TD is configured to require the same password for all of the reinitialize device requests. 6. The TD is configured to contain file names that would not be accepted by the OS which the IUT is running on. 7. The TD is configured with a Protocol_Revision < The TD is configured with a Protocol_Revision 10. This is only used if the IUT claims Protocol_Revision 10. Note that if IUT claims Protocol_Revision < 10, the presence of preparation time properties in a TD with Protocol_Revision 10 may be ignored and cannot be relied upon. Restore Characteristics: 1. The TD is configured to support CreateObject service, and some of the configuration files exist while others do not. 2. The TD is configured such that some of the configuration file File objects exist, but the file size is different from that of the file to be restored. 3. The TD is configured to not support the CreateObject service. 10

11 4. The TD is configured to contain some configuration files that are STREAM_ACCESS and some that are RECORD_ACCESS. 5. The TD is configured to only allow access to File and Device objects during the Backup and Restore procedures. All other attempts shall result in an error from the TD. 6. The TD is configured to require the same password for all of the reinitialize device requests. 7. The TD is configured with a Protocol_Revision < The TD is configured with a Protocol_Revision 10. This is only used if the IUT claims Protocol_Revision 10. Note that if IUT claims Protocol_Revision < 10, the presence of preparation time properties in a TD with Protocol_Revision 10 may be ignored and cannot be relied upon. 1. MAKE (IUT initiate a backup on the TD device) 2. WAIT (for backup to complete) 3. MAKE (changes required in TD to meet restore characteristics for this test) 4. MAKE (IUT initiate a restore on the TD device) 5. WAIT (for restore to complete) 6. CHECK (that the file content restored is the same as the file content that was backed up) Notes to Tester: Other items to ensure were correct during execution of the test: 1. Verify the order the IUT read the configuration files was the same as the order returned by the Configuration_Files property. 2. Verify that any file with a File_Size of zero was restored. 3. Verify that each file read is in byte order if STREAM_ACCESS and in record order if RECORD_ACCESS. 11

12 BTL-TP 12.0g-2: Update Averaging Object Tests Overview: BTL-CR-0309 clarified that in the Averaging object, there is no requirement where in the first window, the first sample is taken. Change tests and to start with taking two samples, since there is no way to know, nor importance attached to knowing, when within the window the sample will occur. Changes: [In BTL Test Plan, change references to from to BTL] [In BTL Specified Tests, Add new tests derived from ] Reinitializing the Samples Purpose: To verify that an Averaging object correctly resets the Attempted_Samples, Valid_Samples, Minimum_Value, Average_Value, and Maximum_Value when Attempted_Samples, Object_Property_Reference, Window_Interval, or Window_Samples are changed. Test Concept: The IUT is configured with an Averaging object that is actively monitoring some property value. The sampling is reinitialized by writing to the Attempted_Samples, Object_Property_Reference, Window_Interval, Window_Samples, and Window_SamplesObject_Property_Reference in turn. After each reinitialization, the TD pauses and verifyies that new sampling has begun. Configuration Requirements: The IUT shall be configured with an Averaging object that is actively monitoring some property value. The sampling interval shall be long enough to permit the TD to verify that the sample is properly reinitialized. [Renumber remaining steps to close the gaps for those which are now omitted.] 1. VERIFY Minimum_Value = (a value x: -INF < x < INF), 2. VERIFY Average_Value = (a value NaN), 3. VERIFY Maximum_Value = (a value x: Minimum_Value x < INF), 4. VERIFY Attempted_Samples = (a value x > 0), 5. VERIFY Valid_Samples = (a value x > 0), 6. WRITE Attempted_Samples = 0, 7. VERIFY Attempted_Samples = 0, 8. VERIFY Minimum_Value = INF, 9. VERIFY Maximum_Value = -INF, 10. VERIFY Average_Value = NaN, 11. VERIFY Valid_Samples = 0, 12. WAIT (at least two sample times), 13. VERIFY Minimum_Value = (a value x: -INF < x < INF), 14. VERIFY Average_Value = (a value NaN), 15. VERIFY Maximum_Value = (a value x: Minimum_Value x < INF), 16. VERIFY Attempted_Samples = (a value x 2), 17. VERIFY Valid_Samples = (a value x 2), 18. WRITE Window_Interval = (any new value that will result in an appropriate sample time), 19. VERIFY Attempted_Samples = 0, 20. VERIFY Minimum_Value = INF, 21. VERIFY Maximum_Value = -INF, 22. VERIFY Average_Value = NaN, 23. VERIFY Valid_Samples = 0, 24. WAIT (at least two sample times), 25. VERIFY Minimum_Value = (a value x: -INF < x < INF), 26. VERIFY Average_Value = (a value NaN), 12

13 27. VERIFY Maximum_Value = (a value x: Minimum_Value x < INF), 28. VERIFY Attempted_Samples = (a value x 2), 29. VERIFY Valid_Samples = (a value x 2), 30. WRITE Window_Samples = (any new value that will result in an appropriate sample time), 31. VERIFY Attempted_Samples = 0, 32. VERIFY Minimum_Value = INF, 33. VERIFY Maximum_Value = -INF, 34. VERIFY Average_Value = NaN, 35. VERIFY Valid_Samples = 0, 36. IF (Object_Property_Reference is writable) THEN { WAIT (at least two sample times), VERIFY Minimum_Value = (a value x: -INF < x < INF), VERIFY Average_Value = (a value NaN), VERIFY Maximum_Value = (a value x: Minimum_Value x < INF), VERIFY Attempted_Samples = (a value x 2), VERIFY Valid_Samples = (a value x 2), WRITE Object_Property_Reference = (any new value), IF ( Samples_are_taken_immediately) THEN { VERIFY Attempted_Samples = 1, VERIFY Minimum_Value = Average_Value,, VERIFY Maximum_Value = Average_Value, VERIFY Valid_Samples = 1 VERIFY Attempted_Samples = 0, VERIFY Minimum_Value = INF, VERIFY Maximum_Value = -INF, VERIFY Average_Value = NaN, VERIFY Valid_Samples = 0 [In BTL Test Plan, change references to from to BTL] [In BTL Specified Tests, Add new tests derived from ] Managing the Sample Window Purpose: To verify that an Averaging object correctly tracks the average, minimum, and maximum values attained in a sample. This includes monitoring before and after the sampling window is full. Test Concept: An Averaging object is configured to monitor a property that can be controlled manually by the testing agent or by the TD. The TD initializes the sample and then monitors the Minimum_Value, Average_Value, Maximum_Value, Attempted_Samples, and Valid_Samples properties after each sampling interval to verify that their values are properly tracking the monitored value. This requires the ability to manipulate the values of the monitored property value and a slow enough sampling interval to permit the analysis. This continues until after the sample window is full. If the IUT does not support Averaging object configuration for this Test Concept, then this test shall be omitted. Configuration Requirements: The IUT shall be configured with an Averaging object used to monitor a property that can be controlled by the testing agent or by the TD. The sampling interval shall be configured to allow time to change the monitored property value and to determine if each of the properties Minimum_Value, Average_Value, Maximum_Value, Attempted_Samples, and Valid_Samples correctly changes after each sample interval. 1. WRITE Attempted_Samples = 0, 2. VERIFY Attempted_Samples = 0, 3. VERIFY Minimum_Value = INF, 4. VERIFY Maximum_Value = -INF, 5. VERIFY Average_Value = NaN, 6. VERIFY Valid_Samples = 0, 2. READ StartingSample = Valid_Samples +1 13

14 73. REPEAT X = (1StartingSample to Window_Samples + 5) DO { WAIT (Window_Interval / Window_Samples) IF (X Window_Samples) THEN VERIFY Attempted_Samples = X VERIFY Attempted_Samples = Window_Samples, VERIFY Minimum_Value = (the minimum of the monitored values so far), VERIFY Maximum_Value = (the maximum of the monitored values so far), VERIFY Average_Value = (the average of the monitored values so far), IF (X Window_Samples) THEN VERIFY Valid_Samples = X VERIFY Valid_Samples = Window_Samples 14

15 BTL-TP 12.0g-3: Clarify AE-INFO-B Requirements Overview: BTL-CR-0310 clarified the requirements of AE-INFO-B. One of the functionalities tested in AE-INFO-B actually applies only when both AE-INFO-B and AE-ACK-B are claimed, so deserves a Checklist line item to separate it that way. Changes: [In BTL Test Plan, move test, and add section, as follows] 5.15 Alarm and Event - Information - B Base Requirements Base requirements must be met by any IUT claiming conformance to this BIBB Event Information Based on Acknowledged_Transitions Test Method Manual Configuration As per ASHRAE [In BTL Test Plan, add section with preamble under AE-INFO-B, as follows] Supports AE-ACK-B The IUT initiates EventNotifications with service parameter AckRequired = True Event Information Based on Acknowledged_Transitions Test Method Manual Configuration As per ASHRAE [In BTL Checklist, add section named: Supports AE-ACK-B under AE_INFO-B] Alarm and Event - Information B R Base Requirements O Supports AE-ACK-B 15

16 BTL-TP 12.0g-4: Modify Network Tests to handle Unicast I-Ams Overview: q allows the I-Am service to be sent as a unicast message. The Network and BBMD tests need to be changed to accommodate this change. (see also BTL-CR-0248) The Network and BBMD tests used SA and DA everywhere, but are thus incorrect in some cases when SOURCE and DESTINATION are on different networks. Existing tests need to be changed to accommodate this. All SA = IUT and DA=IUT which appear, are removed, since that is the default. Changes: This makes changes to all tests in sections 14.1 and 14.2 and 14.7 that use the I-Am service, to allow the unicast form of the response. There are parallel changes still needed in sections 9.24 and 9.33 where I-Am is used explicitly, in some cases as a proxy for a Broadcast generally. When Addendum ar-5 is ratified, parallel changes will be needed for I-Have in section [In BTL Test Plan, modify test references to tests 14.1 listed below from e to BTL] [In BTL Specified Tests, Add the following tests to section 14.1, based on e-1 (or )] Forwarded-NPDU (One-hop Distribution) Purpose: To verify that an IUT, not configured as a BBMD, will process a Forwarded-NPDU message. Configuration Requirements: The IUT shall not be configured as a BBMD. The TD shall be on a different IP subnet than that of the IUT. 1. TRANSMIT DA = Directed IP Broadcast to IUT s IP Subnet, SA = TD, Originating-Device = TD, 2. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = TD, SA = IUT, Original-Unicast-NPDU, RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, 3. CHECK (The IUT shall not issue any Forwarded-NPDUs) Original-Broadcast-NPDU Purpose: To verify that an IUT, not configured as a BBMD, will process an Original-Broadcast-NPDU message. 1. TRANSMIT DA = Local IP Broadcast, SA = TD, Original-Broadcast-NPDU, 2. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = TD, SA = IUT, Original-Unicast-NPDU, 16

17 RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, 3. CHECK (The IUT shall not issue any Forwarded-NPDUs) Forwarded-NPDU (Two-hop Distribution) Purpose: To verify that an IUT, not configured as a BBMD, will process a Forwarded-NPDU message. Configuration Requirements: The IUT should not be configured as a BBMD. The TD shall be on the same subnet as the IUT. D1 is a device on a different IP subnet than the TD. 1. TRANSMIT DA = Local IP Broadcast, SA = TD, Originating-Device = D1, 2. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = D1, SA = IUT, Original-Unicast-NPDU, RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, 3. CHECK (The IUT shall not issue any Forwarded-NPDUs) [In BTL Specified Tests, Add the following tests to section 14.2, based on ] Execute Forwarded-NPDU (One-hop Distribution) Configuration Requirements: The IUT shall be configured with a BDT that contains: B/IP Address IUT BBMD1 Broadcast Distribution Mask IP Subnet 1 subnet mask IP Subnet 2 subnet mask 1. TRANSMIT DA = Directed IP Broadcast to IP Subnet 1, SA = BBMD1, Originating-Device = BBMD1, 2. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = BBMD1, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast on IP Subnet 1, SA = IUT, Original-Broadcast-NPDU, 17

18 3. RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT ) 4. CHECK (The IUT does not forward or resend the Who-Is packet out the port on which it was received) Notes to Tester: The order of the messages transmitted by the IUT is not significant Execute Forwarded-NPDU (Two-hop Distribution) Configuration Requirements: The IUT shall be configured with a BDT that contains: B/IP Address Broadcast Distribution Mask IUT BBMD TRANSMIT DA = IUT, SOURCEA = BBMD1, Originating-Device = BBMD1, 2. RECEIVE DA = Local IP Broadcast on IP Subnet 1, SA = IUT, Originating-Device = BBMD1, 3. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = BBMD1, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast on IP Subnet 1, SA = IUT, Original-Broadcast-NPDU, 4. RECEIVE DA = BBMD1, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Execute Original-Broadcast-NPDU (One-hop Distribution) Configuration Requirements: The IUT shall be configured with a BDT that contains: B/IP Address Broadcast Distribution Mask 18

19 IUT BBMD1 IP Subnet 1 subnet mask IP Subnet 2 subnet mask 1. TRANSMIT DA = Local IP Broadcast, SA = D1, Original-Broadcast-NPDU, 2. RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT Originating-Device = D1, 3. RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, 4. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = D1, Original-Unicast-NPDU, RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT Notes to Tester: The order of the messages transmitted by the IUT is not significant Execute Original-Broadcast-NPDU (Two-hop Distribution) Configuration Requirements: The IUT shall be configured with a BDT that contains: B/IP Address Broadcast Distribution Mask IUT BBMD TRANSMIT DA = Local IP Broadcast, SA = D1, Original-Broadcast-NPDU, 2. RECEIVE DA = BBMD1, SA = IUT, Originating-Device = D1, 3. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = D1, 19

20 Original-Unicast-NPDU, RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, 4. RECEIVE DA=BBMD1, SA=IUT, Notes to Tester: The order of the messages transmitted by the IUT is not significant. [In BTL Specified Tests, Add the following tests to section 14.7, based on ] Broadcast Message from Directly Connected IP Subnet (One-hop Distribution) Configuration Requirements: The IUT s BDT shall contain the following three entries: B/IP Address Broadcast Distribution Mask IUT IP Subnet 1 subnet mask BBMD1 IP Subnet 2 subnet mask BBMD2 IP Subnet 3 subnet mask The TD shall be on the same subnet as the IUT. D1 is a device on a different IP subnet than the TD. Steps 2-5 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 6 is steps 6-10 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = Local IP Broadcast, SA = D1, Original-Broadcast-NPDU, 2. RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT, Originating-Device = D1, 3. RECEIVE DA = Directed IP Broadcast to IP Subnet 3, SA = IUT, Originating-Device = D1, 4. RECEIVE DA = FD1, SA = IUT, Originating-Device = D1, 5. RECEIVE DA = FD2, SA = IUT, 20

21 Originating-Device = D1, 6. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = D1, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT, RECEIVE DA = Directed IP Broadcast to IP Subnet 3, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Broadcast Message from Directly Connected IP Subnet (Two-hop Distribution) Configuration Requirements: The BDT shall contain the following three entries: B/IP Address Broadcast Distribution Mask IUT BBMD BBMD Steps 2-5 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 6 is steps 6-10 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = Local IP Broadcast, SA = D1, Original-Broadcast-NPDU, 2. RECEIVE DA = BBMD1, SA = IUT, Originating-Device = D1, 3. RECEIVE DA = BBMD2, SA = IUT, Originating-Device = D1, 4. RECEIVE DA = FD1, SA = IUT, Originating-Device = D1, 5. RECEIVE DA = FD2, SA = IUT, 21

22 Originating-Device = D1, 6. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = D1, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = BBMD1, SA = IUT, RECEIVE DA = BBMD2, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Broadcast Message Forwarded by a Peer BBMD (One-hop Distribution) Configuration Requirements: The BDT shall be configured as in test Steps 2-3 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 4 is steps 4-8 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = Directed IP Broadcast to IP Subnet 1, SA = BBMD1, Originating-Device = D2, 2. RECEIVE DA = FD1, SA = IUT, Originating-Device = D2, 3. RECEIVE DA = FD2, SA = IUT, Originating-Device = D2, 4. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = D2, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT, 22

23 RECEIVE DA = Directed IP Broadcast to IP Subnet 3, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Broadcast Message Forwarded by a Peer BBMD (Two-hop Distribution) Configuration Requirements: The BDT shall be configured as in test Steps 2-4 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 5 is steps 5-9 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = IUT, SOURCEA = BBMD1, Originating-Device = D2, 2. RECEIVE DA = Local IP Broadcast, SA = IUT, Originating-Device = D2, 3. RECEIVE DA = FD1, SA = IUT, Originating-Device = D2, 4. RECEIVE DA = FD2, SA = IUT, Originating-Device = D2, 5. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DAESTINATION = D2, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = BBMD1, SA = IUT, RECEIVE DA = BBMD2, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, 23

24 ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Broadcast Message From a Foreign Device (One-hop Distribution) Configuration Requirements: The BDT shall be configured as in test Steps 2-5 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 6 is steps 6-10 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = IUT, SA = FD1, Distribute-Broadcast-To-Network, 2. RECEIVE DA = Local IP Broadcast, SA = IUT, Originating-Device = FD1, 3. RECEIVE DA = BBMD1, SA = IUT, Originating-Device = FD1, 4. RECEIVE DA = BBMD2, SA = IUT, Originating-Device = FD1, 5. RECEIVE DA = FD2, SA = IUT, Originating-Device = FD1, 6. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = FD1, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = Directed IP Broadcast to IP Subnet 2, SA = IUT, RECEIVE DA = Directed IP Broadcast to IP Subnet 3, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant Broadcast Message From a Foreign Device (Two-hop Distribution) 24

25 Configuration Requirements: The BDT and FDT shall be configured as in test Steps 2-5 are the distribution of the Who-Is request to the devices considered to be members of the BACnet network, step 6 is steps 6-10 are the distribution of the I-Am response from the local application. 1. TRANSMIT DA = IUT, SA = FD1, Distribute-Broadcast-To-Network, 2. RECEIVE DA = Local IP Broadcast, SA = IUT, Originating-Device = FD1, 3. RECEIVE DA = BBMD1, SA = IUT, Originating-Device = FD1, 4. RECEIVE DA = BBMD2, SA = IUT, Originating-Device = FD1, 5. RECEIVE DA = FD2, SA = IUT, Originating-Device = FD1, 6. IF (the IUT responds with Unicast I-Am) THEN RECEIVE DA = FD1, SA = IUT, Original-Unicast-NPDU, (RECEIVE DA = Local IP Broadcast, SA = IUT, Original-Broadcast-NPDU, RECEIVE DA = BBMD1, SA = IUT, RECEIVE DA = BBMD2, SA = IUT, RECEIVE DA = FD1, SA = IUT, RECEIVE DA = FD2, SA = IUT, ) Notes to Tester: The order of the messages transmitted by the IUT is not significant. 25

26 BTL-TP 12.0g-5: Update Password Handling Tests Overview: The existing tests for Backup & Restore with invalid password should also test the effect of requests where a password is missing when one is required, and acknowledge that the standard has changed over time. The standard mandated Error Class: SERVICES Error Code: SERVICE_REQUEST_DENIED in Protocol_Revision 4, as follows: Preparation for Backup... If device B is unable to perform a backup procedure or is already performing a backup procedure, then it will respond to the ReinitializeDevice service request with a 'Result(-)' response. Assuming device B supports the backup procedure and the request was properly formulated, the valid Error Class:Error Codes that can be returned are : DEVICE:CONFIGURATION_IN_PROGRESS - if device B is already processing a backup or a restore request. SERVICES:SERVICE_REQUEST_DENIED if the password that was provided was incorrect or if a password is required and one was not provided. After device B responds to the ReinitializeDevice request with a 'Result(+)', the configuration File objects must exist in the device. It is a local matter as to whether device B will respond to other requests while it is in backup mode. The exception to this is that device B must accept and fulfill read requests by device A that consist of accesses to device B's Device object and/or its configuration File objects. Any services that are rejected due to an in-progress backup procedure will be rejected with an error class of DEVICE and error code of DEVICE_BUSY. It is a local matter as to whether device B will continue to perform control actions while it is in backup mode. If device B changes its operational behavior during a backup procedure, then the System_Status property of the Device object shall be set to BACKUP_IN_PROGRESS Preparation for Restore... Upon receipt of the restore request, if device B is able to perform a restore procedure, device B will prepare for the restore procedure and will respond with a 'Result(+)' to the ReinitializeDevice service request. If device B is unable to perform a restore procedure, then it will respond to the ReinitializeDevice service request with a 'Result(-)' response. Assuming device B supports the restore procedure and the request was properly formulated, the valid Error Class:Error Codes that can be returned are: DEVICE:CONFIGURATION_IN_PROGRESS if device B is already processing a backup or a restore request. SERVICES:SERVICE_REQUEST_DENIED if the password that was provided was incorrect or if a password is required and one was not provided.... Then later that was revised in Protocol_Revision 7, and the tests should acknowledge that change with a Protocol_Revision conditional. Changes: This makes changes to tests in section for STARTBACKUP and STARTRESTORE and different changes in the similar tests in that use COLDSTART and WARMSTART, including combining the formerly separate tests for when the password is invalid vs when a password is missing but one is required. [In BTL Specified Tests, add tests and derived from ] COLDSTART with Missing or Invalid Password 26

27 Purpose: To verify that the correct BACnet Error PDU is returned when a COLDSTART is attempted andthe password is invalid or a password is required but no password is provided. 1. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = COLDSTART, 2. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) (BACnet-Error-PDU, Error Class = SERVIVCES, Error Code = MISSING_REQUIRED_PARAMETER) 3. CHECK (The IUT did NOT perform a COLDSTART reboot) 4. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = COLDSTART, Password = (any invalid password) 5. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) (BACnet-Error-PDU, Error Class = SERVIVCES, Error Code = MISSING_REQUIRED_PARAMETER) 6. CHECK (The IUT did NOT perform a COLDSTART reboot) WARMSTART with Missing or Invalid Password Purpose: To verify that the correct BACnet Error PDU is returned when a WARMSTART is attempted and the password is invalid or a password is required but no password is provided. 1. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = WARMSTART, 2. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, 27

28 Error Code = SERVICE_REQUEST_DENIED) (BACnet-Error-PDU, Error Class = SERVICES, Error Code = MISSING_REQUIRED_PARAMETER) 3. CHECK (The IUT did NOT perform a WARMSTART reboot) 4. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = WARMSTART, Password = (any invalid password) 5. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) (BACnet-Error-PDU, Error Class = SERVIVCES, Error Code = MISSING_REQUIRED_PARAMETER) 6. CHECK (The IUT did NOT perform a WARMSTART reboot) Notes to Tester: External indications that the IUT has reinitialized, such as LEDs or startup message traffic, shall be used to confirm reinitialization whenever possible. [In BTL Specified Tests, add tests and derived from m] Attempting a Backup Procedure with an Invalid Password Purpose: To verify the correct execution of the Backup procedure when an invalid password is provided and when a password is required but no password is provided. If the IUT cannot be made to deny a ReinitializeDevice <STARTBACKUP> service request that does not contain a valid password, then this test shall be omitted. 1. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = STARTBACKUP, Password = (any invalid password) 2. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) 3. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = STARTBACKUP 4. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE 28

29 (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) Attempting a Restore Procedure with an Invalid Password Purpose: To verify the correct execution of the Restore procedure when an invalid password is provided and when a password is required but no password is provided. If the IUT cannot be made to deny a ReinitializeDevice <STARTRESTORE > service request that does not contain a valid password, then this test shall be omitted. 1. TRANSMIT ReinitializeDevice-Request, Reinitialized State of Device = STARTRESTORE, Password = (any invalid password) 2. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) 3. TRANSMIT ReinitializeDevice-Request, 'Reinitialized State of Device' = STARTRESTORE 4. IF (Protocol_Revision is present and Protocol_Revision >= 7) THEN RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE (RECEIVE BACnet-Error-PDU, Error Class = SECURITY, Error Code = PASSWORD_FAILURE) (RECEIVE BACnet-Error-PDU, Error Class = SERVICES, Error Code = SERVICE_REQUEST_DENIED) [In BTL Test Plan, reference those tests as the versions in BTL Specified Tests, and entirely eliminate reference to tests and ] Implements ReinitializeDevice with a Password The IUT can deny, or can be made to deny, a ReinitializeDevice service request that does not contain a valid password COLDSTART with a Correct Password Configuration As per ASHRAE

30 WARMSTART with a Correct Password Configuration As per ASHRAE COLDSTART with an Invalid Password Configuration As per ASHRAE WARMSTART with an Invalid Password Configuration As per ASHRAE i-16BTL X3 - COLDSTART with mmissing or Invalid Password Configuration As per ASHRAE BTL Specified Tests i-16BTL X4 - WARMSTART with mmissing or Invalid Password Configuration As per ASHRAE BTL Specified Tests Supports Password Protected Backup The IUT denies, or can be made to deny, a ReinitializeDevice <STARTBACKUP > service request that does not contain a valid password BTL Attempting Backup with an Invalid Password Configuration As per ASHRAE BTL Specified Tests. 30