Jim's notes from our 10-Aug discussion of NOvA DAQ SW and DDS

Partial summary of meeting:

We talked about a lot of ideas and directions. I think we saw a mix of problems that were being addressed in the discussion, including: building of test stands, controls system interfaces and lower-level software, DAQ-related functionality, and higher-level applications such as cluster monitoring.

In the end, we have the nova DAQ to worry about, which may be a subset (in the short term at least) of the entire problem we were talking through. Nova does have this interesting fact that they will be using EPICS for their control system. Easy integration with that system could be a big bonus for the control room. We do need a few very good use cases to determine the best answer to this problem.

We talked about several technologies and how and where to use them. Here are some of the scenarios or points:

data model issues

How should message or data to be sent/received be modeled? I prefer an object model in UML, with a generator that produces DDS-IDL and perhaps other structures or code to help access it from various languages.

An EPICS record type can be generated for each of the modeled data. A generic DDS device can be assigned to these records that subscribes to the related topic and fills out the data in the record, thus causing as channel access client to be noticed of the new data. There are many details here to be worked out, such as buffering and what PV names go to what published thing.


The event builder near the DCM as an EPICS IOC. This means learning EPICS and using it.

EPICS as a relay

The current prototype does this.

DDS as backbone with EPICS bridges

have internal component in the data path publish DDS messages, have a fancy EPICS CA server that subscribes to all things and fabricates PVs based on what it sees.

actionscript as the GUI

let actionscript subscribe to data through a gateway or bridge process into the DDS world. find or develop a flexible gui that allows placement of widget and dynamic activation.


  1. the run control broadcasts and the wait for acknowledgment from everyone.
  2. the action directed to a particular process if acknowledgment does not work
  3. using DDS in the event builder (for QOS features) - must be careful of multicast here to everyone
  4. simple alarm manager that listens for any posted alarm.


  1. where and why is EPICS (or something like it) useful? What problems does it solve?
  2. where and why is DDS useful? What problems does it address?
  3. what other technologies are useful in solving the various problems?
  4. what are the negatives to using above (1) and (2) systems?

For (1), EPICS has many Channel Access (CA) clients to do necessary work in a full system, such as archiving, GUI building, alarm management.

For (2), decoupling is nice, robust behavior (QOS features), handling of structured data. lighter weight API?

We covered much of the answers to the above questions, but I have not filled the answers in yet.

Other groups and technologies:

  • Note that DES and LSST seemt to be using labview as their telescope control system. Note that LSST appears to be using DDS as the underlying message passing system.
  • We've looked at the SAF frameworks, one of which uses TIPC as its protocol for message passing
  • LSST is also looking into a real time publish-subscribe system (do not know much of this)
  • Ron mentioned TINE as another full control system.