A. Portas

The TJ-II data acquisition system: an overview

The data acquisition system for the TJ-II fusion machine has been developed to coordinate actions among the several experimental systems devoted to data capture and storage: instrumentation mainframes (VXI, VME, CAMAC), control systems of diagnostics and a host-centralized database. Connectivity between these elements is achieved through local area networks, which ensure both good connections and system growth capability. Three hundred VXI based digitizer channels have been developed for TJ-II diagnostics. They are completely software programmable and provide signal analog conditioning. In addition, some of them supply a programmable DSP for real time signal processing. Data will be stored in a central server using a special compression technique that allows compaction rates of over 80%. A specific application software has been developed to provide user interface for digitizer programming, signal visualization and data processing during TJ-II discharges. The software is an event based application that can be remotely launched from any X terminal. An authentication mechanism restricts access to authorised users only.

Data management in the TJ-II multi-layer database

Abstract The handling of TJ-II experimental data is performed by means of several software modules. These modules provide the resources for data capture, data storage and management, data access as well as general-purpose data visualisation. Here we describe the module related to data storage and management. We begin by introducing the categories in which data can be classified. Then, we describe the TJ-II data flow through the several file systems involved, before discussing the architecture of the TJ-II database. We review the concept of the ‘discharge file’ and identify the drawbacks that would result from a direct application of this idea to the TJ-II data. In order to overcome these drawbacks, we propose alternatives based on our concepts of signal family, user work-group and data priority. Finally, we present a model for signal storage. This model is in accordance with the database architecture and provides a proper framework for managing the TJ-II experimental data. In the model, the information is organised in layers and is distributed according to the generality of the information, from the common fields of all signals (first layer), passing through the specific records of signal families (second layer) and reaching the particular information of individual signals (third layer).

Accessing TJ-II data with remote procedure call

A new software, based on the de facto standard Open Network Computing Remote Procedure Call (ONC RPC) has been developed for TJ-II database access. This software solution replaces a previous development based on Berkeley sockets in which the client implementation had the drawback that was platform dependent. From the user point of view, the access to the TJ-II database can be done from codes running in the central server or from any other computer in the network in exactly the same way. From the development point of view, the ONC RPC tools allow to generate source code for the clients in an easy and flexible manner, thus reducing the work needed to maintain/upgrade the library for different platforms. The access to the database is managed by a concurrent server program, running on the central server, which implements each access routine as a service on the network. This allows controlling the accesses to the database. A client library has been developed to provide connection with the data server. This lib...

Design of the TJ-II remote participation system

The TJ-II remote participation design has focused initially on providing remote access to elements that depend exclusively on characteristics of the TJ-II environment: data acquisition, data access, and diagnostics control systems. Aspects related to advanced display tools, audio information from the control room or videoconference sessions can be addressed, at least in a first step, by using standard solutions. Remote access will be accomplished through http servers and web browsers as they are standard elements available on all platforms. Access security rests on a validation scheme in which users are identified through a username and password, these data being transferred in a secure way by using a secure socket layer (SSL). After username and password validation, the security system assigns a session ticket to the user, in which the user profile (access authorization list) is encoded. User profiles determine several access levels to the system. Such levels delimit the authorizations for accessing different services according to the allowed degree of interaction of remote users with the TJ-II environment. The ticket will be sent in every user query, in order to test user permission for the requested action. Services can be classified into five groups: Measurement channel setup, read/write access to the TJ-II databases (raw data, analyzed data, elaborated data, and relational databases), diagnostic control system monitoring/programming, advanced data acquisition system configuration and, finally, reading/writing information on TJ-II operation logbook. The TJ-II remote participation system is strongly coupled with the local data acquisition system.

TJ-II data retrieving by means of a client/server model

The database of the TJ-II flexible heliac is centralized in a Unix server. This computer also commands the on-line processes related to data acquisition during TJ-II discharges: programming of measurement systems, connectivity with control systems, data visualization, and computations. The server has to provide access to the data so that signal analysis can be performed by local users or even from remote hosts. Data retrieving is accomplished by means of a client/server architecture in which two data servers are permanently running in the background of the Unix computer. One of them serves data requests from local clients and the other one sends data to remote clients. The communication protocol in both cases has been developed by using TCP/IP and Berkeley sockets. The client part consists of a set of routines (FORTRAN and C callable), which, in a transparent way, provide connectivity with the servers. This structure allows access to TJ-II data exactly in the same way from any computer, hiding not only sp...

A relational database for physical data from TJ-II discharges

Abstract A relational database (RDB) has been developed for classifying TJ-II experimental data according to physical criteria. Two objectives have been achieved: the design and the implementation of the database and the software tools for data access depending on a single software driver. TJ-II data were arranged in several tables with a flexible design, speedy performance, efficient search capacity and adaptability to meet present and future, requirements. The software has been developed to allow the access to the TJ-II RDB from a variety of computer platforms ( alpha axp /True64 unix , cray / unicos , Intel Linux, Sparc/Solaris and Intel/Windows 95/98/NT) and programming languages ( fortran and c / c ++). The database resides in a Windows NT Server computer and is managed by Microsoft SQL Server. The access software is based on open network computing remote procedure call and follows client/server model. A server program running in the Windows NT computer controls data access. Operations on the database (through a local ODBC connection) are performed according to predefined permission protocols. A client library providing a set of basic functions for data integration and retrieval has been built in both static and dynamic link versions. The dynamic version is essential in accessing RDB data from 4GL environments (IDL and PV-WAVE among others).

Software architecture of data acquisition control process during TJ-II operation

Data from the diagnostics on the TJ-II device will be collected by several independent systems linked to local area networks (LANs). Some of these systems will consist of digitizers based on well-known standards: CAMAC, VME, VXI, etc. Other allowable systems would be personal computers or workstations with direct control over a specific diagnostic. In principal, any equipment capable of being linked in a LAN can be used as a controller for data collection. All systems will be programmed from a central computer. In this computer, an application program will allow the set up of data acquisition in any system. This will be achieved by communicating systems through a network standard protocol: TCP/IP. The central computer will also centralize the database of discharges. For this purpose, immediately after a discharge, data will be sent from the autonomous systems to the main computer. The latter will coordinate data reception, organize discharge information, and compress data. Data will be transferred rapidly...