IEEE Transactions on Nuclear Science, Vol. NS-26, No. 4, August 1979

THE SUPPORT OF MULTIPLE DATA STREAMS IN A DYNAMICALLY CONFIGURED SOFTWARE SYSTEM**

Joseph E. Kulaga and John W. Tippie

ABSTRACT

This paper discusses a modular data-acquisitionsystem that allows on-line, dynamic configurationof software to meet a user's particular acquisitionand analysis needs. The support of multiple datastreams, typically consisting of a raw data streamand one or more derived data streams, is emphasized.Examples are given, including a real-time datatransformation of multiparameter events thatoperates in a two-parameter data space.

INTRODUCTION

The software system described in this paperwas developed to meet the ever-changing data-acquisition and analysis needs of the physicistscarrying out the low- and medium-energy nuclearphysics research programs of the Physics Divisionof Argonne National Laboratory. Figure 1illustrates the typical hardware of the four

Fig. 1. Typical hardware configuration.

*Work performed underDepartment of Energy.

the auspices of the U. S.

Joseph E. KulagaPhysics Division

John W. TippieApplied Mathematics Division

Argonne National LaboratoryArgonne, Illinois 60439

similarly configured independent computer systemsbased on the Digital Equipment CorporationPDP-11/45 processor. Two systems are on-line tothe Tandem and Dynamitron accelerators, another inan instrumented trailer for off-site experiments,and a fourth is used for off-line data analysis andsoftware development. A typical experimentconsists of acquiring data from one or more nuclearparticle detectors and performing pulse-heightanalysis into several one-and two-parameter spectra.

The system was implemented under DEC'sDOS/BATCH-ll operating system and consists of aresident section written in Macro assembly languageand over 100 user-oriented Fortran overlaysproviding well over 200 separate functions. Oneof the key components of the system is the CommandLanguage Processor (CLP)12 which executes in thebackground in the resident section and isresponsible for accepting user commands and takingthe appropriate action. Commands are acceptedfrom a number of terminal devices, or from commandsequence files residing on disk. Each user commandevokes one of three supported types of functioncalls: a resident function call, a linked overlaycall, or a command sequence file. Residentfunctions are part of the resident system code andusually perform simple operations such as settinginternal flags. Linked overlay functions areloaded into core by the CLP and executed. Theseoverlays supply the functionality required by thephysicist: definition of variable acquisition andanalysis schemes, interactive graphics, hardcopyplotting on electrostatic printer/plotters andCalcomp, kinematics calculations, equipment control,and others. Sequences, the third class of supportedfunctions, are user generated disk files containinga series of function calls (or other sequence calls)which a user may wish to execute frequently. Eachrecord of a sequence file is a separate functioncall which the CLP executes sequentially. Librarysubroutines are provided for command line parsingand present an effective, easy to use parameterretrieval mechanism. These routines allow theinclusion of function option "switches ," "sub-command" strings (typically used with the inter-active graphics functions), and alphanumericparameter strings, up to a total of 160 bytes fora command line. The CLP is shown schematically inFig. 2.

Another key software component is an extensivedataset management routine package which allows forthe dynamic allocation and use of blocks of memoryor disk space to be referenced by name. Thisestablishes a uniform dataset access mechanismspanning both physical memory and disk space,referencing logical blocks much the same as filestructures are handled on direct access diskvolumes, regardless of physical location. Memoryis classified as "local memory" for datasetsallocated from the DOS buffer pool (below 28KW) andas "extended memory" for those allocated above 28KW

0018-9499/79/0800-4489$00.75© 1979 IEEE 4489

Space may be allocated in as small a unit as a32-word block, and up to a maximum of 64K words.These Fortran callable dynamic memory managementroutines provide features that are essential tothe dynamic configuration of the acquisitionsoftware to be described.

REAL-TIME SOFTWARE LINKAGES

Fig. 2. Command language processor.

which must be accessed by mapping the memoryrelocation hardware (see Fig. 3). At present,"local memory" is used for the foregroundacquisition and analysis routines, control blocks,and buffers, while extended memory is used fornuclear spectrum datasets, graphics control blocks,and large parameter arrays.

To provide maximum flexibility and minimizememory usage, the base-line system contains noresident acquisition or analysis software. Instead,the user calls system overlay functions to definethe data source hardware and the analysis methods

] he requires. These functions, in turn, dynamicallyload the device-dependent data-acquisition routinesand the device-independent pulse-height analysisand data-transformation routines into memory usingthe dynamic memory management routines describedabove. The acquisition and analysis software iswritten in position independent and reentrant codeand executes in the foreground. These routinesexist as pure code (with linkages to an experiment-dependent control block) and may be shared amongmany independent processes, where appropriate(e.g., all one-parameter spectra may be producedby the same pulse-height analysis routine,referenced by a spectrum-dependent control block).

The linkages that exist in the foregroundroutines are most easily understood when viewedpictorially. A user defines the hardwaregenerating his raw data by calling the systemfunction DFNSRC ("define source") and supplyingthe required information. The result of this callis the in-core data structure depicted in Fig. 4,

120K

Extended 3Memory 32K

ExtendedResident Bit MapSubroutineLibrary 24K

Co.smmand LanguaeProce"or

Common 17" Flg,BScratch Area & Parame

Overlay -16KFunctionLoad Area

Buffer PoorForegroundRoutines

ResidentDOS Modules

j..._DOS -4

Deviceinterrupt

Memory

ufferseters

8K

InterruptVectors

PHA Pule Height AnalygsRMU Return from baterruptRTS Return from Subroutine

- > Pointer.- t.> Interrupt- > oram flow

Fig. 3. Memory map for data-acquisitionsystem. Fig. 4. Data structures after DFNSRC call.

4490

which represents the allocation of four local memorydatasets and their interconnecting pointers. Inoperation, a hardware interrupt vectors to a "data-acquisition control block" (DAQCB) which transferscontrol to the appropriate device-dependent acquisi-tion module. The device driver retrieves neededinformation from the DAQCB, such as the length andlocation of the double buffers. When the devicedriver completely fills the input buffer, it performsa buffer swap and issues a programmed interruptrequest to an "analysis chain" (null in Fig. 4)concluded by a termination routine which merelysignals when processing is complete. If a userissued a START command with the structure of Fig. 4,data would be collected into the input buffer and,in the absence of any analysis specification,effectively be thrown away.

On-line data analysis may be initiated bycalling additional system overlays to define adesired pulse-height analysis (PEA) method or datatransformation. Figure 5 illustrates the effect of

A Palm diMn dnu 3su fo SdrTIaa

-------P>.Ibtw.....> ------C Pigs am

Fig. 5. Insertion of pulse-height analysisroutine.

specifying a one-parameter PEA of one data elementof a logical data event. A PHA control block isinterted in doubly linked list fashion into the"analysis chain," a nuclear spectrum dataset isallocated, and the appropriate PEA real-timemodule is dynamically loaded, with linkagesestablished as shown. When a programmed interruptrequest is issued down the analysis chain, controlis transferred to the PHA routine via the controlblock and the analysis is performed. Whenprocessing is complete, control is transferred tothe next item in the chain, in this case, thetermination routine. In a typical experimentinvolving events consisting of four coincidentparameters, a user might request that eachparameter be pulse-height analyzed, in which casethe analysis chain consists of four consecutivePHA control blocks referencing the same shareablePHA code. The user may also evoke the

I obarwo Wr.trmt

two-parameter PHA routines, or any one or more ofthe data-transformation routines to be applied tothe same raw data stream. A routine which isusually in this stream is the event-mode datarecording module which is responsible forbuffering up and writing all raw data ontomagnetic tape in a standard format for later off-line analysis. There is no inherent limit to thenumber of data processing modules that may beapplied along the same data path.

SUPPORT OF MULTIPLE DATA STREAMS

Unique among the available real-time analysissoftware is a subset whose usage brings about thecreation of uniquely defined, independent datasource streams derived from the raw data. Thiscapability grew out of a need encountered in theheavy-ion research program in the Physics Division.A plot (Fig. 6) of the heavy evaporation residuesof the decay of a compound nucleus shows a number

C., FUSION DATA0 N - Ne 13C + 12C

FNa

mg

Fig. 6. User defined acceptance window ina two parameter data space.

of particle groups of differing charge exhibitingcontours with compound curvature in theEtotal vs AE two-parameter data space. A real-time filtering routine was required by thephysicists to scan the incoming raw data andaccept only those events which fell within a userdefined contour in the Etotal vs AE space, asindicated in Fig. 6. It was decided to constructa filtered data stream whose "list head" filterdata source control block (FDSCB) had a structureidentical in form and content to a raw datasource control block. The FDSCB thus heads a newanalysis chain with its own data buffers andtermination mechanism. The real-time filterroutine (and its control block) is inserted intothe raw data stream and copies into the filtereddata stream buffer only those events which passthrough the acceptance window. In analyzing thisfusion data, the experimenter typically applies afilter on the raw data stream to effect a chargeseparation of the data, and then applies a secondlevel filter to the first filtered data stream toeffect a mass separation of the data. The in-core

4491

.Im

Pulse Height Analysis

Return hfo InterruptRTS Retur om ubune

-- > PointerCD> Inetrrpt

- D> flow

* Sharoebi. re^trant ode

Fig. 7. Linkages for three independent data streams.

data structure for this triple data stream config-uration can be seen in Fig. 7. (Note also thepresence of the event mode tape recording routinein the raw data stream.)

The key concepts allowing these complex datastructures to be created are: uniformity of controlstructures, uniformity of access methods, and thecapability of dynamically allocating and linkingin-core datasets. Any routine acting on the dataof a given data stream is insensitive to itslocation on the analysis chain and independent ofthe source type, i.e., raw or derived data. Thisapproach is easy to use since each data stream isgiven a unique name, either by the system for thehardware sources of raw data, or by the user forderived data. (For example, the first levelfiltered data may be given the name "Fl" and thesecond level "F2".) The most elaborate use of thisfacility to date consists of a tree structure oftwelve applications of the filtering mechanism!

The concept of creating a derived data streamhas most recently been extended to include two newand very different applications. In the first,four pairs of (x,y) coordinate data are collectedfrom wire chambers of a pion spectrometer and a raytracing algorithm must be executed in real-time tocalculate the five corresponding orbit parametersfor a detected pion. It was decided that the samedata structure involved in filtering would beappropriate, except that instead of copying accepteddata into a new data source stream, the routinescans the raw data, calculates the orbit parameters,and passes the results to a new data stream. Theevent-by-event tape routine is used on the raw datastream to record the raw events for later, moreextensive off-line analysis. As with the filter,both raw and processed data streams are availableto be pulse-height analyzed in any manner theexperimenter sees fit.

4492

A second application of this technique wasprompted by the development of a focal planeionization-chamber for use with the split-polespectrograph. In a manner analogous to the pionray tracing application, a routine was required toprocess the raw data and generate a new stream ofmore meaningful data. The effect of this real-timeroutine is to linearize the positions sensed on tworesistive-wire proportional counters and match theirsensitivity, as well as correcting Etotal for lossesin a foil, correcting AE for varying entrance angle,and calculating the entrance angle accurately. Thisroutine further allows the experimenter to definea virtual focal plane for this detector,effectively increasing the sensitivity of thedetector to various particle groups which wouldotherwise require physically re-positioning theunit in the spectrograph- a time consuming operationon-line, and an impossibility when viewing the dataoff-line. It is this application which also makesextensive use of the filtering mechanism toseparate out the various particle groups detectedand which, in fact, typically requires over onedozen data streams be simultaneously active!

CONCLUSIONS

The use of a dynamic memory managementfacility has led the way to the development of anextremely powerful data analysis tool. The supportof multiple data streams has allowed complexanalysis procedures that would be extremelydifficult to consider implementing in some otherfashion. These tools allow the experimenter tomake more effective use of his own time, inaddition to making more effective use of hison-line beam time.

REFERENCES

1. J. W. Tippie and J. E. Kulaga, "Modular-Programmed Data Acquisition/Analysis inResearch", American Laboratory 8, No. 10,Oct. 1976.

2. J. W. Tippie and J. E. Kulaga, "A CommandLanguage Based Data-Acquisition and AnalysisSystem for Low-Energy Physics," IEEETransactions on Nuclear Science, NS-24(l),(1977), pp. 492.

3. J. E. Kulaga and J. W. Tippie, "Data Acquisitionand Control via CAMAC," Proceedings of theDigital Equipment Computer Users Society,Vol. 4, No. 2, Fall (1977), pp. 597.

4493