Kurt's responses and notes from our 10-Aug NOvA DAQ and DDS discussion

Conclusions so far (sent to Jim). I expect that we'll iterate on these as we learn more, and as we think more about the issues.

  1. At this point, I am not comfortable recommending that EPICS be used as the framework for the NOvA DAQ. This is based on several factors, all of which are somewhat subjective:
    1. EPICS is a control system, not a DAQ system. Steve and I looked at EPICS the first time around and decided that it was not a good fit, but of course, that could have been biased by a lack of understanding of EPICS.
    2. There is a substantial learning curve for EPICS, and I don't want to foist that on the rest of the DAQ SW team nor do I feel that it would be politically acceptable to suspend development on DAQ SW while Luciano and I go off to become EPICS experts.
    3. EPICS is not a panacea (you and Ron listed some of the disadvantages yesterday), and it is not clear to me that the advantages (existing tools and infrastructure) outweigh the poor fit (IMO) for some of the DAQ-specific needs that I keep trotting out (transition requests, message logging).
    4. However, I will present the idea of using EPICS at this week's NOvA DAQ SW meeting. As you say, there would be advantages to using EPICS for both slow controls and DAQ, and I'm interested in hearing whether the DAQ group views such a thing favorably or not.
    5. Of course, if you decide that we need to seriously consider EPICS for the NOvA DAQ (you're the boss, after all), we will do that, but the ramifications that come to mind include A) I think that it would take at least several months for Luciano and I to become familiar enough with EPICS to make informed judgments, and B) that time could be viewed as a diversion by NOvA project management so we would need to handle it delicately and possibly charge that time to an internal task code rather than NOvA.
  2. We definitely should generate a list of requirements and selected use cases for a DAQ system. This will be useful for defining what we mean when we talk about a DAQ system, sharing that information with collaborators, and evaluating existing frameworks. Luciano and I will do this, hopefully on a reasonable time scale.
  3. I'll look into using DDS IDL for generating the message objects in RMS. I don't understand the UML-to-IDL step that you propose, so I'll figure out what that entails. (My view of it will probably come down to ease-of-use. That is, will it be easier for NOvA DAQ SW people to create UML or IDL when it comes time to create a new message?)
  4. We should consider DDS for the transport layer in the event builder code. As several people have mentioned, there are advantages to using an existing networking package rather than writing custom socket code. Luciano and I should discuss this.
  5. In the absence of the use of an existing framework (e.g. EPICS), we should make as many subsystems as possible as reusable as possible for future experiments. For example, the message logging subsystem seems like an excellent candidate for reuse on a future experiment or teststand. Of course, this may mean that it can be used without RMS. Or maybe RMS becomes less relevant anyway once we start using DDS. In any case, as we discussed, if we can define reusable interfaces with alternative, pluggable backends, then it makes things more useful going forward.
  6. In the absence of the use of an existing framework (e.g. EPICS), we'll need to investigate end-user GUI builders when the time comes to address that need in NOvA.
  7. As we define interfaces to subsystems, we'll keep technologies like Flex/ActiveScript in mind.
Jim's recommendations in response to the list above:
  1. It makes sense to not move to EPICS for the NOvA DAQ, but more because of 1.2 above rather than 1.1 or 1.3.
  2. The DAQ system requirements should include use cases or scenarios to make the needs clear. (Try to model the behavioral aspects of a typical DAQ system.) Also, it would be very helpful to describe typical state behavior.
  3. For describing the data model for messages, UML should be easier. Visual Paradigm, Community Edition is a tool that can handle the design of message classes.
  4. Talk to Mark Fishler about his Message Logger to see how it can be used for NOvA. It already has lots of nice features, especially on the message production side.
  5. Plan for "trace" functionality from the beginning.
  6. Make the following functionality available and advertise it to the DAQ SW group: publish DAQ system statistics from a soft IOC so that the EPICS system being used for DCS can have access to them.
  7. Use Redmine instead of the plone wiki or CRL.
  8. Meet again sometime to discuss package directory structures and build environments.