One CalibConfiguration object is the access point for all the calibration data in the crate. In the DAL this is the only object which uses OKS. It is responsible for creating all the other objects. This is the only class which would need replacing in the offline environment - all the other classes could remain unchanged.
There is one XxxSettings object for each module. This can be
linked to the equivalent module object in the hardware configuration
database. In OKS it would make sense for them to share the same
unique ID (this only has to be unique within one class [check!]).
The settings object for each module then contains a number of objects
with the data to be loaded into each distinct device on the module.
It is expected that the software will implement hardware access to
each device in separate objects of an appropriate class, so this
division of calibration data into one chunk per device is probably
the most appropriate - rather than an object per channel or per
module.
However the PPrAsic needs to be downloaded with several different
calibrations per channel, so here there is some further subdivision.
The CalibConfiguration and module settings objects would probably
be kept in one file, separate from the device settings.
This file should be fairly static, while the device data files can
change - as long as the OKS unique IDs of the device data objects in
new calibration files match those expected in the top level file.
The following sections describe some of the calibration data
classes in a bit more detail.