Update spec according to already applied implementation changes to cyclic uploads of CC by slidingWindow for improved stability

spec/MicroWaveDeviceInventory+config.json

@@ -335,7 +335,7 @@
               "maximum": 10
             },
             "integer-profile-configuration": {
-              "integer-value": 1
+              "integer-value": 0
             }
           }
         },

spec/MicroWaveDeviceInventory+profileInstances.yaml

@@ -186,7 +186,7 @@ profile-instances:
       minimum: 0
       maximum: 10
     configuration:
-      integer-value: 1
+      integer-value: 0
 
   - profile-name: 'IntegerProfile'
     uuid: 'mwdi-2-0-1-integer-p-003'

spec/additionalDescription/CyclicControlConstructRetrievalProcess.md

@@ -40,7 +40,7 @@ The profileInstances relevant to the update process are *slidingWindowSize*, *re
 - Due to timeouts, connection errors or other issues it may not be possible to retrieve the CC for a given device. In order to not lose to much data, there can be retries for the CC retrieval.
 - **When a device from the slidingWindow is queried and the retrieval fails, the retrieval should be retried as many times as configured in maximumNumberOfRetries.**
 - **The allowed retries shall also be applied to the qualityMeasurement process**
-- (initial) configuration: 1
+- (initial) configuration: 0
 
 **`deviceListSyncPeriod`**  
 - **The deviceListSyncPeriod determines in which intervals the MWDI deviceMetadataList is synced with the list of (connected) devices from the Controller**
@@ -131,7 +131,7 @@ The slidingWindow approach is still used, but the selection mechanism of the nex
 Also the slidingWindow approach works in tandem with the qualityMeasurement process in keeping the cache up-to-date.
 
 **Device selection strategy**  
-When either a ControlConstruct retrieval in the slidingWindow finishes and a new slot opens or when the qualityMeasurement process needs to find the next update candidate, the next candidate device is taken from the front of the deviceMetadataList.
+When either a ControlConstruct retrieval in the slidingWindow finishes and a new slot opens or when the qualityMeasurement process needs to find the next update candidate, the next candidate device is taken from the front to the back of the deviceMetadataList.  
 Both processes only consider devices in connected state which are not locked.
 - **_slidingWindow_**: take the first (connected, unlocked) device from the deviceMetadataList
   - this is either a device for which currently no ControlConstruct is stored in the cache
@@ -148,6 +148,12 @@ Both processes only consider devices in connected state which are not locked.
 The following schema shows how both processes are working collaboratively on updating the cache (the pink and blue devices are those currently processed and, therefore are locked):  
 ![IntegratedCollaboration](./pictures/integratedSlidingWindowQualityMeas.png)
 
+### Stability update with MWDI 2.0.1
+
+For improved stability the following changes have been introduced from 2.0.0 to 2.0.1:
+- sliding window retries are deactivated; for this purpose `maximumNumberOfRetries` is set to 0
+- devices are no longer moved to the end of the sliding window
+- retrieval priority is determined from *last-complete-control-construct-update-time-attempt*
 
 ### DeviceMetadataList metadata
 The metadata table introduced in 1.2.x is replaced by the deviceMetadataList metadata attributes. I.e. the deviceMetadataList no longer consists only of the devices, but also stores the additional metadata attributes.  

spec/additionalDescription/DeviceListMetadataDescription.md

@@ -88,7 +88,7 @@ By providing the mappings in the *deviceTypeMapping* and *vendorFromDeviceMappin
 
 ## Sorting the deviceMetadataList
 
-In order to effiently select the next device for ControlConstruct update by either the slidingWindow or qualityMeasurement process, the deviceMetadataList is sorted by priority.  
+In order to efficiently select the next device for ControlConstruct update by either the slidingWindow or qualityMeasurement process, the deviceMetadataList is sorted by priority.  
 The ordering is based on the the *last-complete-control-construct-update-time-attempt* timestamp values, with from-oldest-to-newest order, starting with those devices where the timestamp is from *1999*.
 Devices with connection-state not being *connected* are found at the end of the list (if they are being kept due to the *historicalControlConstructPolicy*).