A Variable should need to have same number of HasHistoricalConfiguration references to nodes of HistoricalDataConfigurationType as it has historized logs.
We expect that it should be possible for a client to use the NodeId of nodes of HistoricalDataConfigurationType to request a HistoryRead service (ReadRaw) from a server.
When testing with UaExpert, as client, we get "Added item does not support historizing" when requesting a HistoryRead service from the nodes of HistoricalDataConfigurationType but it works if requesting it from the Variable (but in that case it is not possible to select what historized log to get data from).
It is possible to set HistoryRead in UserAccessLevel and Historizing to true for the Variable but not for the nodes of HistoricalDataConfigurationType and that may be the issue but then the question arises:
How should it be possible for a client to select the historized log to get historical data from if it is not possible to request the HistoryRead service from the nodes of HistoricalDataConfigurationType ?
Any clarification of this situation is apricated.
It does not make sense to pass an Object to request History Data. You can only request History Data for Variables.
While the HasHistoricalConfiguration does allow for the possibility of a single Variable having multiple HistoricalConfiguration Objects it seems that possibility was not considered in any other aspect of the History services. It is not clear what multiple HistoricalConfiguration Objects would actually mean (i.e. do they refer to distinct overlapping archives or are they non-overlapping time ranges within the same archive?).
You should put a Mantis issue so the WG can discuss and figure what was intended.
In the meantime, you will need multiple variables to represent each of your historized logs. I suggest a composite Variable with a property for Log1, Log2, etc. You could make a subtype of HasProperty called HasHistorizedLog to make it really clear what those Properties are for.
Part 11 does not define how a historian works only how data is accessed from it.
An object can only have Historical event data (it has not value to store or retrieve)
For Variables, there are many historians that only collect Raw data and compute other types of data on the fly (i.e. they have only one configuration Object for a given variable). Since storage of data has gotten so in expensive and storing years worth of very high resolution data is possible, and processing power has also improved, there is much less of a reason to store anything else.
Some Historian do define additional data collection, where they have raw data and then some type of aggregate data or other definition of how the value is calculated. Also some historians might define data collections with different setting such as sampling intervals, where high speed data (high resolution) is kept for a short period of time and low speed data (lower resolution) is kept for much longer time. In these cases additional configuration object would be created.
The Historian can match what is being requested by a client to the available collections based on their own logic. Typically client requests for raw data always returns the highest resolution available for the time frame requested. If a process data request matches what has already be collected and stored, then it is used to return the values. Look at the ReadProcessedDetails structure for how this can be mapped to historical configurations
The configuration objects are less about how the historian is actually configured, but more about letting the client know that there is historical data for the variable and some information about that historical data (it is compressed, it is just sampled or exception based, when collection started...).
hopefully this explibnation of what was intended helps. If you have any suggestion for changes or other requests please enter a mantis issue as Randy suggests.
Paul Hunkar - DSInteroperability