There are two distinctive data sources and one dependent data source.

DS1: Device.

DS2: User.

DS3: Result of settings/policies/updates.

For the alpha version, only the first two data sources are used.

Data coming from any source are of one of the three natures:

DN1: DS-dedicated data. These resulting data are dependent on the respective DS only and are not affected by anything else. Updating such data may result in alert set, statistics updated but *never* in the original data being overwritten/updated/exported directly from another DS. Example of such data: amount of dropped packets on a network interface. Another example: profile for a device type, the profile being defined by a user.

DN2: DS-computed data. This data are never achieved directly from a DS but are result of an operation using data from multiple DSes or multiple devices. Example of such data: Number of devices of a particular type in the system.

DN3: multi-DS dependent data. Means a data that could be updated by more than one DS and change from one DS typically ends up in an automatic or manual action, that may lead to another change of the data. Examples of such data are: Installed FW version on a particular device; Hostname of a device.

For DN3, it is important to undersand that for each such piece of data, there is a "desired" state and a number of "reported" states. One of the "reported" states is also the "actual" state and the target situation is that the "actual" state should match the "desired" state. Example:

 - Device running Conel OS reports firmware version 6.1.8. [DS1, DN3: "reported actual"]
 - Device is using profile "general" (post-alpha) [DS2, DN1: user]
 - Profile "general" has set the FW to "last approved" [DS2, DN1: user]
 - "Last approved" version in the system is 6.1.8 (there are newer ones available [DS3, DN1: https://ep.advantech-bb.cz/firmware] but not yet approved [DS2, DN1: user])
 - The device-specific settings for FW version is empty at the moment [DS2, DN1: user]

The "desired" version for such device FW version is taken like this (in this particular case):
 - Take version from device specific settings. If not approved, emit alert, exit. If empty, continue.
 - Take version from device profile. If not approved, emit alert, exit. If empty, continue. (post-alpha)
 - Take "reported actual" version.

Looking at the above specific example, the desired version os 6.1.8. Desired and "reported actual" matches, no action needed.

If a user now sets the devices specific settings to 6.1.7 and if the 6.1.7 is available and approved, the 6.1.7 becomes desired and desired now differs from "actual". This would result into data export telling the device to download and flash to 6.1.7 once the device contacts the MAMAS and downloads the last data file.

In a post-alpha stage, also a user approving a newer FW than 6.1.8 would lead to data export requiring the device to flash the firmware (if there was no manual setting to 6.1.7 of course). The chain of events would be: user approving newer FW (let's say 6.2.5), profile "general" noticing the change in the last approved version, marking all the devices using this profile and not being on 6.2.5 fro export and finally all data files for all of such devices being exported.

In both examples above, the "desired" state becomes different from the "actual" state and thus the data file is exported. It will get exported over and over again until device performs the flash and the "actual" state equals "desired" (or until the "desired" changes back to match the "actual" as a result of some user action). Device not updating the state to the desired one over a period of contacts or a period of time may result in alerts being raised (post-alpha).