ORCA Overview


ORCA stands for Object-oriented Real-time Control and Acquisition. ORCA is a data acquisition application for the MacOS X operating system. The goal is to provide a general purpose, highly modular, object-oriented, acquisition and control system that is easy to use, develop, and maintain. To this end, ORCA is written using the MacOS X Cocoa application framework development environment and Objective-C. Its general-purpose design enables a user to easily configure it at run-time to represent different hardware configurations and data read-out schemes.


ORCA also uses many ideas that were developed at the Center for Experimental Nuclear Physics and Astrophysics for the SNO Hardware Acquisition and Real-time Control (SHaRC) DAQ software that is used to read out the PMT array of the SNO experiment.


The ORCA software architecture is based on the Model-View-Controller (MVC) design pattern that is common in object-oriented design. In this case, the models are sets of independent object-oriented software modules that correspond directly to hardware objects, data acquisition tasks, control modules, or data analysis modules. The views are associated dialogs or user interface elements that only deal with displaying a model’s data or state. The controllers arbitrate between the models and the views by passing data from the models to the views and passing user interactions from the views back to the models. Just one model, view, and controller generally represent each piece of hardware, but in some cases models may have multiple views and controllers.


Each one of these objects is comprised of its own fully encapsulated data structures and support and diagnostic code.  ORCA provides an application framework in which these software models can be connected together to represent systems of hardware, and can hence be thought of as being parts of an “Object-oriented Software Bus” (OSB), analogous to a standard hardware bus. This analogy is particularly useful when one of the objects represents a VME crate, for example, into which one can plug VME card objects.


A key design feature of ORCA is the design of the internal, acquired data stream and how this stream is written out for permanent storage. Each hardware object is responsible for writing out both its hardware parameter settings as well as the actual data it acquires. A supervisory data collection object controls which hardware objects are used in the experiment and the order and hierarchy of the read-out scheme. In this fashion a user can completely reconfigure the experimental hardware and the data read-out without rewriting any code or re-compiling the application.


ORCA has a typical mouse-controlled drag and drop graphical user interface that allows a user to select objects from an object catalog and drag them into a configuration window at run time. The following shows a screen shot of the main ORCA configuration dialog configured for use fairly complex experiment (the NCD experiment).

 

Each icon in the configuration window represents either an actual physical piece of hardware or a data chain element that can be double-clicked to bring up a control dialog. Also note that the icons have connection points that can be connected to define the flow of data and commands. All connections and system configurations are done at run-time so that no recompilation of ORCA is needed to reconfigure the application for a different experimental setup. Configurations can be saved and recalled as ORCA documents. All system activities are logged and can be viewed in a status window. System-wide errors are counted and shown in the error window. In addition, you can keep a log book of your activities. The content of the status log and the log book can e-mailed on demand.


A generic run control object has been built into ORCA that allows the type of run to be set by an operator. Runs can be of a predetermined length of time and they can be repeating or single shot runs. Of course, they can be stopped or restarted with the push of a button. Run numbers are automatically assigned for each experiment. There is also a set of run identification bits that can be set to uniquely label special run-time conditions that need to be known during analysis.


During a run, a data monitor object can be used to monitor the quality of the data. The data monitor uses the data description section of the data stream to feed the data into a proxy object of the same type that originally generated the data. The proxy decodes the data and it is entered into a data catalog from which all histograms or waveforms can be selected and viewed as plots. All objects that follow the proper protocol will be able to participate automatically in the use of the data monitor viewer. Offline analysis applications must rely on documentation to be able decode the data stream.


In addition to storing the data on a local disk file, ORCA can stream the data thru a dispatcher socket to any connected applications and has an option to remote copy the data files to another machine at the end of a run. Clients connecting after a run has already started will get the original data description and parameter sections of the data stream but will have lost data up until the time that the connection is established.