Implements most data acquisition behaviour, provided as a library.

Features

Library provides functionality to:

Perform data acquisition by acting as a client to one or more data sources using daq::Manager. Individual data acquisitions are performed with daq::DaqController whereas the daq::Manager owns and multiplexes requests to the correct daq::DaqController instance, with an interface that suits the presented OCM client interface.
Monitor primary data sources for active daq::DaqControllers to react when acquisition is stopped or fails. The MAL subscriber for a source are owned by daq::PrimSource and managed by daq::DaqController (TBC).
Store data acquisition information persistently so it can be resumed if OCM process is restarted (daq::Manager) (TODO).

Design

Concurrency and Thread Safety

OCM must support multiple concurrent (and independent) data acquisitions. Additionally the problem domain is identified to be I/O bound rather than CPU bound so parallelism is not necessary. This is reflected in the design as:

libdaq is fully asynchronous using promise/futures.
Classes accept a boost::asio::io_context or in other cases an executor compatible with boost::thread::Executor concept. It is assumed that the tree of objects referencing each other share a single threaded executor.

Data Acquisition State Recovery

Capability of data acquisition state recovery in non-transitory data acquisition states. E.g. if application is restarted while sources are acquiring the state can be recovered after restart.

If application is restarted some state transition information might be lost and it is ultimately up to the client to perform the correct action based on their information. libdaq will however try to recover the current state at startup.

This is reflected in the design in a few ways:

daq::Status is serializable.
metadaqif::MetaDaq provides a method to query the status.
daq::DaqController provide a full interface instead of a single "perform acquisition". This eventually extends to the user API so they have the ultimate control. Commands may still fail due to lack of authoratative information which is currently not addressed.

Data Acquisition Sequencing

Although we believe a data acquisition sequence (metadata acquisition source started before and stopped after primary data sources) is going to be standard, there might be use-cases that are not foreseen. Therefore it is important that the sequencing is not strongly coupled to the implementation.

This is reflected in the design as:

daq::DaqController accepts abstract asynchronos operations (daq::AsyncOperations).

Todo List

daq::Status is the data structure that records the output of a daq. There will be a similar data structure that records the input of a daq (settings, sources etc.). This is tentatively daq::DaqProperties.

Who has responsibility for these aspects:

Executing serialization of data acquisition to persitant storage
Executing deserialization (load at startup?)

Record history of events for each data acquisition by

Adding to ObservableStatus the ability to record events..
Create observer that (in the future stores events persistently in e.g. the OLDB or other database) the events.