Useful email from Giovanna¶
"As you know the application framework is mainly in DF and partially in CCM. It implements the interfaces towards the CCM services (reception/response to commands, connection to the configuration DB, use of logging and monitoring plugins) and provides the main structure for all applications moving raw or derived data in the trigger and DAQ system.
While on the CCM side we are defining requirements that all sub-systems shall respect (in order to be able to achieve the required flexibility and resilience), on the DF side it is indeed time to have an in-depth revision of the framework provided by artdaq. We started the discussion last spring and a few points were already highlighted:
- reception of different (arbitrary) commands (with arguments) that may be used for error recovery;
- ability to customise the applications, beyond the FragmentGenerator plugin provided today;
- more loose coupling of the framework with the message passing libraries, thus allowing for an easier modification of message types, I/O patterns, etc; this should also help simplifying fault tolerance/recovery;
- possibly ability to extend the FSM (though I’m not sure this will really be needed in DUNE: if the system is meant to be always running and components shall be able to restart independently of the others, the FSM is sort of irrelevant).
As you can imagine, finalising the design of the application framework will be one of the main goals of the DAQ workshop.
On the CCM side, we will have to take things in steps, since we cannot destroy everything we have today and not have a working system for 3 years. One of the big blocks that we will need to tackle sooner rather than later is configuration. A good configuration model is fundamental to avoid having a rigid system with little/no reconfigurability. "