Thoughts on artdaq interfaces

12-Aug-2016, KAB - Georgia and others are thinking about interfaces between artdaq and other subsystems in preparation for a protoDUNE DAQ review in Fall 2016. She suggested using material from DUNE 35-ton, and we should check for any documentation that is available from there. In addition to that, here are some initial ideas.

25-Aug-2016, JCF - added in ganglia, messageviewer, 0MQ, updates to monitoring software model

  1. interaction with detector electronics
    • these are implemented as FragmentGenerators in artdaq, and they provide the mechanism for configuring the electronics and reading it out
  2. responding to control commands
    • this is currently done with XMLRPC
  3. interactions with the computers, networking, Linux operating system, and disks in the DAQ cluster
  4. running of art analysis modules (online monitoring) within eventbuilder and aggregator processes (35ton) or within art, receiving data from artdaq via multicast (protodune).
  5. reporting of DAQ monitoring metrics
  6. reporting of status & error messages
  7. connections with slow controls (sending DAQ monitoring metrics and adding slow controls data to the data stream)
  8. (limited) interaction with configuration management (conduit for detector electronics configuration; storing of configuration data in the art/ROOT file, sent as a string in the init command
  9. need for synchronized data fragments
  10. communication of backpressure to upstream components and possible the trigger system
  11. communication of messages and DAQ statistics up to run control via 0MQ, using lbne-artdaq's DAQLogger and RCReporter modules
  12. communication of DAQ statistics to ganglia
  13. communication of messages to the messageviewer application