UNIDAQ

M.Nomachi, Y.Yasu
KEK, Oho 1-1, Tsukuba, Japan 305

R.Ball
U.Michigan, The Harrison M.Randall Laboratory of physics, 
Ann Arbor, Michigan 48109-1120

A.Fry, C.Erbas
SSCL, 2550 Beckleymeade Avenue, Dallas, Texas 75237

Y.Takeuchi
Tokyo Institute of Technology, Meguro, Tokyo, Japan 152

C. Timmermans
148 Tate Lab. of Physics, U. Minnesota, Minneapolis, MN 55455

Abstract
	
	UNIDAQ is a UNIX based data-acquisition system designed for the portable data-acquisition system primarily for the Solenoidal Detector Collaboration (SDC) testing and development.  The UNIDAQ group, which is KEK, LBL, U.Michigan, SSCL and Tokyo Inst. of Tech., defined the UNIDAQ base-line.
	UNIDAQ is highly portable data-acquisition system.  It runs on SUN, DEC, SGI and HP platforms.  VxWorks is also supported.

I. Introduction
	UNIDAQ is a UNIX based data-acquisition system.  The UNIDAQ group attempts to define the base-line for the portable data-acquisition system primarily for the Solenoidal Detector Collaboration (SDC) testing and development at various locations throughout the collaboration.  The UNIDAQ group, which is KEK, LBL, U.Michigan, SSCL and Tokyo Inst. of Tech., defines the base-line for the system and shares the UNIDAQ development. [1]
II. Philosophy
	The SDC collaboration requires data acquisition capabilities at many locations.  The computer environment on those locations are very much different from each other.  We had to define the base-line so as we can provide uniform capabilities in reduced costs.  It requires scalability from small system to high performance system and portability.  	UNIDAQ runs on standard UNIX.  It does not require any special modification on an operating system.  Therefore, UNIDAQ is highly portable data-acquisition system.  It runs on SUN under SUNOS and Solaris, DEC under ultrix and Alpha OSF-1, SGI and HP platforms.  VxWorks and LynxOS are also supported for the users who needs real-time capability.
	UNIDAQ is developed by the collaboration.  The UNIDAQ group had to define the interface among the data acquisition modules so as the collaborators could share the effort of the development.  As the consequence, UNIDAQ is highly modular system.  It is easy to pick-up a part of the system for one's application from UNIDAQ.  It is also easy to add or replace pieces of data acquisition parts.
III. Open platform
	We chose VME as a hardware platform of UNIDAQ.  Because VME is an industrial standard.  Many of work-stations have the interface to VME.  Many of peripherals like CAMAC have the interface on VME.  UNIDAQ supports CAMAC access through VME-bus.  It supports Kinetics system's K2917 VME interface and K3922 CAMAC crate controller.[2,3,4]  Figure 1 shows CAMAC access layers on UNIDAQ.  The VME interfaces supported by UNIDAQ are Solflower's SFVME, Performance technologies PT-SBS-915, DEC's Turbo-channel VME interface and SPARC VME boards.  CES's VIC-bus and BIT3's interface is optionally supported.  CAMAC library on DEC, SUN, HP and VxWorks is provided with the common user interface

User program	
CAMAC Library	
Ultrix
driver	SUNOS
driver	VxWorks
driver	
Turbo
Channel
VME	SFVME
100	PTISB
915	SPARC
2CE	MVME
167	
VME	
K2917 VME interface	
K3922 Crate controller	
CAMAC	

Figure 1. CAMAC access layers
IV. Real-time responses
	Data acquisition system requires good interrupt response.  UNIX had been classified that it has no real-time capability.  However, high performance processors show good inter process communication response as shown in table 1.  The other real-time capabilities for data acquisition system is also measured in the reference 5 and 6.

Table 1. IPC Response

Platform	IPC Response
(µsec)	
HP742rt	12	
Alpha OSF1	13	
DEC2000/125	67	
Sparc2 SunOS	114	
Sparc2 Solaris	79	

	UNIX has good real-time response in average value.  However, there is no guaranteed response time that real-time operating system has.  The measurements of the distribution of real-time response time were shown in the reference 7.  Do we need guaranteed response time on data acquisition system?  If the delayed response does not cause fatal problem, we don't need the guaranteed response.  We need faster response in average.  UNIX has no guaranteed response but faster response.  It is one of the reasons we could chose UNIX as software platform.
V. Overview
	The long write-up describing UNIDAQ is available by SDC note [8] or by anonymous ftp.
	UNIDAQ data-acquisition processes, which are "collector", "recorder", analyzer" and so on, communicate with each other using system V message queue.

Figure 2.  Typical UNIDAQ processes

	Three types of communication path are provided on UNIDAQ.
	1) Data path provides main data stream through the processes.  NOVA buffer manager is developed at KEK. NOVA handles data pointer to the shared data memory.  There is no data copies on one machine.  NOVA transfers the data with TCP/IP socket over another machine.
	2) The command path is used to send commands like begin and stop to processes.  The commands are passed over the network if the process is on another machine.  Run-control process controls the processes with the command path.  One can export local variables so as the other process can access the variables.  Error messages are passed along the command path.  Commands SET and SHOW are provided to access the variables.
	3)  Status path provides the way to report statistics.  The information for error recovery is also provided by status path.
	The figure 2 shows typical example of the process relationship.  The collector process for getting data from VME /CAMAC and put the data on NOVA buffer manager.  The recorder process gets the data buffer from NOVA, and puts them onto a permanent storage.  The analyzer process analyze the data.  The analyzed results are displayed by HBOOK library and PAW.  Templates of those processes are available on the distribution package.  
	Several processes, which are developed by Univ. of Michigan,  make the complex commands to easy to handle.  Runcontrol process execute command sequences.  XPC process takes care the termination of the other processes.  A simple graphical user interface is also provided.  It runs just on the Xlib.  Therefore, it is very portable system.  Of cause, one can plug in one's own user interface.  Tk/Tcl[9] is one of the optional graphical user interface on UNIDAQ.
	Errors and statistics logging is provided with a simple "logbook" process.  The interface to MURMUR, which is developed at Fermilab, is also provided.  One can choose the logging process.
	Data acquisition processes and control/logging processes may be spread across several machines over network.
VI. Present applications
	UNIDAQ is installed and used for SDC beam tests and detector tests at KEK, BNL, CERN, LBL, the University of Michigan, Indiana University, the University of Toronto, the Tokyo Institute of Technology and SSCL.  UNIDAQ is also used at many institutes not only for the SDC but for many fields.  KEK chooses UNIDAQ as a standard data acquisition system.  It is also used for detector and beam tests for g-2 experiment at BNL(AGS821).
VII. Summary and Conclusion
	UNIX based data acquisition system UNIDAQ is successfully developed.  UNIDAQ requires minimum setup on the hardware and the operating system.  It makes UNIDAQ very portable system and easy to be used as a small data-acquisition system.  Many option is also provided for the data acquisition system which require very high performance.  UNIDAQ may meet very wide variety of the requirements.  It keeps growing by replacing a part of the data acquisition modules to better ones.
VIII. References
[1] A.Fry and M.Nomachi, UNIDAQ A Portable Data-Acquisition System for SSC Detector R&D, Eighth conference on real-time computer applications in nuclear, particle and plasma physics, Vancouver,1993,ed. D.Axen and R.Poutissou,p326.
[2] Y.Yasu, et al., POSIX realtime extension and RISC/UNIX data acquisition, Proc. Int. Conf. Computing in High Energy Physics, Annecy, 1992, ed. C.Verkerk and W.Wojcik (CERN92-07,1992)p.627.
[3] Y.Takeuchi, T.Tanimori and Y.Yasu, Development of data acquisition system using RISC/UNIX workstation, Nucl. Instrum. & Methods A328 (1993) 526
[4] C.Erbas, M.Botlo and A.Fry, "Writing Device Drivers for the VxWorks Operating System", SSCL-N-800,Superconducting Super Collider Laboratory, 1992.
[5] Y.Yasu et al., VMEbus based computer and UNIX as infrastructure of DAQ system, CHEP94
[6] Y.Yasu and Y.Tajima, DAQ Performance of Real-time UNIX on New HP VME Board,1993,SDC-93-600,KEK Internal 93-11
[7] Y.Yasu et al., CAMAC Device Driver for DECStation with TURBOchannel-VME adapter., KEK Internal 91-7,1991, (In Japanese)
[8] UNIDAQ collaboration, UNIDAQ Document Set,SDC-93-573, Superconducting Super Collider Laboratory, 1993, or UM-HE-93-29, Univ. of Michigan, 1993.
[9] J.K Ousterhout, "An Introduction to Tk and Tcl", University of California, Berkeley, CA 94720.