Data acquisition monitoring and control include tasks such as online event processing, hardware configuration and control, experiment bookkeeping, alarm handling, and messaging. Integration of this system with the high speed data flow channel will require careful planning to avoid common pitfalls such as incompatible online and offline analysis efforts, duplication of software development, and inefficient and/or inadequate data quality monitoring. Although we have 2 years before hard decisions have to be made concering online strategies, software, etc, now is the time to start thinking about them.
Six broad, overlapping areas in the online were discussed (there are others not covered): slow contols, information management, information transfer, information storage and retrieval, information display, and configuration control.
The main question in slow controls is whether to use EPICS or not. The argument against EPICS is that it is a large, powerful, but cumbersome and expensive system. The cost per control point is high in EPICS for sparse systems like Hall D. It is also important to note that many modern commercial control systems for hardware (e.g. HV controllers) provide all the functionality that EPICS could. We should think in terms of "internet appliances" rather than in terms of dumb devices needing complicated computer systems to control them.
Two information management schemes commonly used in online systems are ``push'' (subscribtion based) and ``pull'' (client/server based) systems; CLAS uses both. Push systems are very powerful and convenient, but the two can coexist easily.
Information transfer via ``middleware'' is common in today's computing environments. The leading solutions today are object-based (e.g. CORBA) and message-based (e.g. SmartSockets) systems. Use of a single middleware system for the entire online (offline?) is probably desirable, although multiple systems can easily coexist.
Databases are powerful and widely used, and Hall D thinking should be ``database-centric'' from the start. The leading contenders are relational and object-oriented databases. The former is widely used and very mature, the latter is more powerful but less mature and less widely used.
There many choices for information display: ROOT, hbook/paw, JAS/Java, HistoScope, web, etc. We probably will use more than one.
Detector configuration control is best done via a grand state machine, perhaps integrated with the CODA run control state machine. The alternatives are pre-run checklists, or operator skill and memory. The former is reliable but tedious, the latter unreliable but widely used (e.g. CLAS).