Developments in networked embedded system technologies and programmable logic are making it possible to develop new, highly flexible data acquisition system (DAQ) architectures. We present a networked DAQ system architecture where the software resources required by the DAQ units are acquired from a server dynamically, to be stored and executed in local memory. When the DAQ unit needs to call an operation not contained in its memory, the new operation is requested from the server, while resources occupied by operations that have not been used recently are released to make space for it. In this way it is possible to reduce the resource use of the embedded DAQ unit to only what is necessary for efficient operation in its major modes. Since new code is easily distributed to the DAQ units from the server, system upgrades are also simplified. Abstract Controlling Server Introduction A distributed data acquisition system offers many advantages, but also increases the system's complexity. This tends to increase the complexity of the code in the embedded,front-end part of the system. Complex code with more functionality has a larger memory footprint, and its complexity can make it is more error-prone. Executing a command is the same as starting a chain of processing before the task is completed. One of the benefits of using a distributed system is the ability to let specific nodes handle specific tasks. This multi-tier architecture also allows extraneous code to be removed from some embedded parts and executed on more suitable nodes. The size Clients for control and monitoring An Operation-Server Based Data Acquisition System Architecture Clyde C. W.Robson, Sam Silverstein and Christian Bohm Fysikum, Stockholm University, SE Stockholm, Sweden Embedded controllers for DAQ The embedded controllers are FPGA based boards, on Virtex-IV FPGAs from Xilinx. They offer a networked based set of commands for control and data acquisition. They can easily be replaced in the system as long as they make use of the in house developed application protocol. At the moment we are using software network protocol stacks for communication, but we are looking into hardware-based solutions for communication to improve performance. Clients for control and monitoring can be written in any language of convenience, as long as they make use of the same protocol. We are currently using LabVIEW for rapid initial development and Java for the production phase. Embedded software DAQ Controller DB Server Client Matlab of the embedded nodes can be further reduced if at any given time only the functions needed in the current running phase are loaded in memory. Our system offers this functionality, as well as the additional benefit that software testing and modification become much easier. We have used this system to implement the controlling software for an in-house developed SPECT camera. By using a common, in-house application level protocol, all nodes can easily access each other and make use of the services that other nodes have to offer. The controlling server functions as the main access point for software clients accessing the system from anywhere in the world. By wrapping in the embedded part of the system and using the embedded controller's services as a basic set of commands, it can also expand the total number of commands-and their complexity-almost indefinitely. By adding services from other nodes these commands can be very complex yet still very transparent to the system user. The controller architecture is designed to be highly adaptable. It is written in C for smaller footprint and good performance.The main body is used for communication and control, and all tasks are implemented as work functions (commands). This object oriented approach makes it easy to work with. The controller can easily be adapted to new situations and tasks by simply replacing commands. Since this can be easily done during runtime, there is no need to restart or redeploy the full system. Because commands use a standardized protocol, they are interchangeable. When a command is received from the Controlling Server, the controller checks whether the requested command is among the deployed commands. If it is, the command is run and the result returned. If not, a request is sent to the Controlling Server for the requested command, When the command is received, it is then loaded and executed. The extra overhead for loading externally stored commands strongly depends on the connection type and speed. We have found that setting up the full connection with a TCP three-way-handshake for each request will take up to four times longer than if the connection is already established (for example, 475 us compared to us.) In our preliminary tests all commands fit in the tcp-data section (total of 1460 bytes), so only one packet needed to be returned. These tests were done on a heavily loaded 100 Mbit network with a fair amount of other activity. For comparison it took an average of 2 us to execute the same command when it was already loaded, so the network part took roughly 98 percent of the execution time! We expect significant future improvement when we switch to a private 1 Gbit network with dedicated servers and controllers. Switch Server PC Server PC Client ADC DAQ Controller ADC DAQ Controller ADC DAQ Controller ADC Links