CODA, The Next Generation

[Elliott Wolin <wolin@jlab.org>]

To all friends of CODA,

Attached is my proposal for the CODA 3.0 user's framework, i.e. the framework within which 
CODA users will deploy their code.  I am sending this to a wide audience to get as much 
feedback as possible.

Note that this is NOT the official DAQ Group position on the subject...this is my proposal 
to the DAQ Group and to its friends.  I welcome any and all feedback, suggestions, and 
discussion.

Thanks,

				Sincerely,
					Elliott


================================================================================


  Those raised in a morally relative or neutral environment will hold
		    no truths to be self-evident.
				

Elliott Wolin
12000 Jefferson Ave MS 6B
Newport News, VA 23606
757-269-7365

================================================================================


                      CODA - The Next Generation
                      --------------------------

                                  or

                        The CODA 3.0 Manifesto


                            Elliott Wolin
                              8-Mar-2005



Below I propose a new user framework for the next generation CODA DAQ
toolkit.  This is a followup to a previous note on CODA objects, which
I have extended based on many suggestions.  In essence I am proposing
an approach, and a set of classes that implement that approach, that
all CODA users will work within.  Legacy code will be supported to a
great extent, of course...my proposal covers the framework within
which new user code will be developed.

Please think about and comment on this approach.  I believe my
proposal satisfies most requests for improvements to CODA, e,g, to
make it more general and simpler to extend.  Note that I am only
discussing the view of CODA seen by users, and not the internal view
seen by CODA authors.

Central to my approach is the notion of CODA "objects" of various
sorts.  One is analogous to the current coda_roc, the process that
runs on vxWorks, accepts interrupts, reads out the high-speed data,
etc.  Other objects have no role in high-speed data taking, and simply
let run control know that some essential system is running.



Introducing CODA Objects
------------------------

I base my object design on four abstract ideas or behaviors which are
realized in a four-level object inheritance hierarchy.  I argue that
these four capture the real-world behaviors of the components of DAQ
and control systems.  Note that little I say below specifically refers
to DAQ systems...the framework can just as easily control a cryo plant
or an online farm as a DAQ system.

The four ideas are: configurable, controllable, transitionable, and
interruptible.  Additional ideas or behaviors, e.g. data_handler or
data_source, will be discussed later.

But first...


What is a "run"
---------------

A run is described by a configuration file, and run control is only
concerned with the components listed in the file.  Some may simply
need to exist while others may take part in run control transitions.
Run control's job is to establish communication with all components in
the config file, verify they are in the proper state, send them
appropriate action commands, and verify the actions are taken.  Run
control further must monitor the health and state of all objects, and
take action if any component spontaneously changes state or
disappears.

Multiple run control sessions may exist, and some objects may
participate in multiple runs.  I note that this is a delicate topic
that has to be approached carefully.



CODA Objects
------------

The base class, CodaObject (the name might change), implements the
"configurable" idea or behavior.  This class includes the virtual or
abstract methods getConfig() and setConfig(), which are user-written
(as are all such methods below).  A CodaObject may be used in multiple
simultaneous runs, i.e. there is no notion of ownership of a
CodaObject by a particular session or run.  Examples include
"slow_controls" or "high_voltage", which might need to be in the
configuration state "RUNNING" or "ON", but which are not exclusive to
a particular run.

A run cannot begin unless all its components are in the state listed
in the config file.  If a component spontaneously switches to a new
state, e.g "high_voltage" switches from "ON" to "STANDBY", run control
will notify the operators and end the run.

Note that a CodaObject may be a data_source.  E.g. the current CLAS
epics_monitor could be implemented as a CodaObject since it simply
injects Epics data into the data stream, and could easily inject into
multiple data streams in separate runs.

The second behavior is "controllable", realized by the SessionObject
class that inherits from CodaObject.  SessionObjects are owned and in
exclusive use by a single run control session, although they may not
be used in all runs in the session.  They must be released when no
longer needed so that other sessions may use them.  The reason they
must be owned is that they implement the virtual methods start(),
stop(), reset(), and exit(), behaviors that cannot cross session
boundaries.  Note that they also implement setSession() and
getSession().

The third behavior is "transitionable", realized by the RunObject
class that inherits from SessionObject.  These components execute CODA
state transitions, and implement the virtual methods getState(),
download(), prestart(), go(), and end(). (is this the appropriate set
of transitions?).

The final behavior is "interruptible", realized by the
InterruptibleObject class that inherits from RunObject.  These
components can react to external interrupts, same as coda_roc does now
for VME interrupts.  These implment the virtual method interrupt(),
which corresponds to the usr_trig() method in coda_roc.

It is possible that SessionObjects might need to be interruptible.  I
believe there is no practical case where this is needed.  Please let
me know if you disagree.



Other Ideas or Behaviors
------------------------

I propose that additional ideas or behaviors, such as data_handler,
data_source, or even user-defined behaviors, be included as interfaces
or pure virtual classes.  E.g. if a SessionObject is also a
data_handler, this should be expressed in the user's code through
multiple (interface) inheritance from SessionObject and from the (as
yet to be defined) data_handler virtual class.

It is not clear which additional behaviors are needed, and what they
should do.  Perhaps these are only needed for monitoring purposes, as
I claim that all essential behaviors are captured in the four classes
above.  Your input here is welcome.



Note on Legacy Approaches
-------------------------

The current readout list paragigm is to write readout code in a
special CRL language using a special template, and then precompile and
compile it.  The compiled file name is listed in a run configuration,
and the code is dynamically downloaded into the roc at runtime.  The
coda_roc task dispatches to the various user-written functions in the
file as needed.

Although this differs from the object-oriented approach described
above, the legacy approach is easily accomodated.  I am currently
writing a concrete implementation of InterruptibleObject that first
receives the shared object file name at download, then dynamically
loads the code, and finally dispatches to the user-written functions
as needed, thus duplicating the legacy functionality.



Current State and What's Next
-----------------------------

I have implemented the first three classes in Java and will port them
to C++ soon.  I have implemented the shell of the fourth class,
InterruptibleObject, but not the code that implements VME bus
interrupt vector handling or Unix-style process interrupt handling.  I
am waiting for agreement on the basic approach before proceeding (this
will likely be written by someone far more expert than me!).  I also
will complete the concrete implementation of InterruptibleObject to
duplicate legacy functionality.

I will test the C++ and Java objects in in a toy run control system
and in the new agent-based run control when it is ready.

Beyond this...not clear yet.  Please get back to me with your
comments, suggestions, diatribes, threats, excommunication edicts,
etc.