- Email: [email protected]
Real-time acquisition and remote monitoring of steady state tokamak (SST-1) diagnostics data
Fusion Engineering and Design 82 (2007) 1198–1202
Real-time acquisition and remote monitoring of steady state tokamak (SST-1) diagnostics data Manika Dey ∗ , H.D. Pujara Institute for Plasma Research, Nr. Indira Bridge, Bhat, Gandhinagar 382428, India Received 31 July 2006; received in revised form 16 January 2007; accepted 22 January 2007 Available online 23 March 2007
Abstract The architecture of data acquisition system (DAS) for the tokamak SST-1 is essentially distributed and heterogeneous. With the long discharge duration of about 1000 s, that imposes a requirement of sampling data for an equally long duration from the variety of fast and slow diagnostics, the challenge is also to cater the need of a real time monitoring of signals by multiple locally networked users. With these objectives, the DAS is based on a model where the objects of the systems are integrated with the Central Control System of SST-1 using the TCP/IP communication. Communication of each object with the Central Server is facilitated with a dedicated, 100 Mbps, fully duplex, Ethernet connection. The DAS software essentially meets the demand of an active remote configuration of hardware digitizers, like PXI system and that of the initialization of acquisition within the local network. The present work describes the TCP/IP based DAS software in labview for configuring, acquiring, and subsequently, pushing the sampled data into network. The focus is also on a client utility for real-time monitoring of SST-1 diagnostics signals by multiple clients during the discharges. We also describe the model implemented for archival and retrieval of SST-1 diagnostics data using an MDSplus server and the model tree, with its sub trees necessitated by the different SST-1 diagnostics system. In addition to this, viewing the SST-1 diagnostics signals across the network using JSCOPE and browsing the signals using Web is also described, along with a matlab plotting tool for the SST-1 diagnostics data. © 2007 Elsevier B.V. All rights reserved. Keywords: Data acquisition; MDSplus
1. Introduction The design and objectives of various subsystems of the tokamak SST-1 [1] are largely influenced by the steady-state mode of operation of the device. The ∗ Corresponding author. Tel.: +91 7923969001; fax: +91 7923969017. E-mail address: [email protected] (M. Dey).
0920-3796/$ – see front matter © 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2007.01.011
scope of the data acquisition system (DAS) for SST-1 is identically wider in comparison with a finite pulsed duration operation device. The SST-1 would implement large number of diagnostics for measurement of different plasma parameters. The plasma diagnostics have requirements for both slow and fast sampling rates in a range, which varies from a few samples per second to a few MHz and the number of channels will be in the order of several hundreds. The DAS thus needs
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
to handle demands for digitization of signals, online display on the hosts, and an archival/retrieval system for post data analysis, for the entire range of slow to fast diagnostics. It also requires monitoring of data on network by different clients for slow diagnostics. The DAS has also an active interface with the Central Control System (CCS) of the device which is equally versatile and largely independent from the DAS. This interfacing between the two is to be facilitated by a well-defined infrastructure involving the communication using TCP/IP protocol. As discussed above, ensuring an exact correspondence between the DAS and CCS has been one of the objectives. While the methodology implemented is discussed further in this paper, in a typical sequence of operations, for example, the CCS passes the shot number to the DAS, which, in turn, provides the corresponding status to the CCS allowing the CCS to provide start/stop trigger to the original DAS element through the timing system. The next important aspect that falls under the scope of DAS is the management and an efficient archival of the acquired data, essentially for subsequent processing and analysis, using the established and widely used standards across the fusion community. In order to achieve this, the standard of MDSplus data archival/retrieval methodology [2] has been implemented. This, along with simplifying the post archival access, facilitates the much desired portability of the acquired data across a heterogeneous pool of, local and/or remotely located, user environments which may consists of machines ranging from the ordinary desktop PCs to the high-end workstations for extensive processing and analysis of the experimental (or even simulated) data. In addition to these, an active monitoring of client and server elements, a bandwidth effective transfer of the data across the local network and the Web, implementation and distribution of a collection of tools for online as well as offline display and simple analysis of the data, are also among the tasks that are covered by the design of the DAS. In this paper we discuss the architecture of the DAS software in Section 2 and the methodology for data monitoring is discussed in Section 3. The implementation of MDSplus standards for DAS and options for data retrieval from the DAS are described in Sections 4 and 5, respectively. A summary of the issues discussed in this paper is present in Section 6.
1199
2. Architecture of the DAS software In order to cater the wide ranging needs of the device and those of the entire user base of SST-1 DAS the architecture of the underlying DAS software is chosen to be distributed and based on the Client/Server architecture as shown schematically in Fig. 1. The main motivation behind the choice of a distributed DAS has been an improved data through-put since the multiple data transfer paths can be established which result into a net reduction in the total load on the network. There are other additional advantages like better extensibility and increased flexibility with respect to the addition of new DAS elements. The SST-1 DAS is largely a PC based DAS system each element of which is responsible for the control of its associated hardware, i.e. for digitizing the data acquired by the respective diagnostic and for the subsequent transport of the same to the central archive. The DAS softwares program various modules for different modes of acquisition, for example, either an event based acquisition or a continuous one. The DAS software uses Labview [4], LabWindows or C for Virtual Instrumentation (CVI). These essentially provide visual development environment and are largely supported, in terms of availability of the corresponding device drivers, by most of the manufacturers of PXI modules. CAMAC and PXI constitute the major part of the data acquisition system. Typically, during the process of acquisition the raw data has to be written to the local hard disk and also pushed on to the local network for monitoring by the clients which reside on the user systems.
Fig. 1. The schematic diagram of the DAS architecture.
1200
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
3. Monitoring As discharge time for the SST-1 device is aimed to be about 1000 s, it is essential to monitor the data by a continuous visualization of a part of it to observe important physical phenomena while a plasma shot is in progress. In view of this at present a dedicated monitoring system is being developed. In general, when the server sends data to different clients for monitoring it is required to be at a reduced sampling rate than the rate at which the original data is being acquired according to user requirements. An alternate way, which is being explored presently, is to transmit the entire sample to the clients in a compressed format and allow the user to select the relevant part that needs to be monitored. The Central Control System can however be supplied with the data at a relatively higher rate, depending on a particular requirement during the discharge. The entire data is simultaneously archived on the local hard drive of a DAS element for the subsequent transfer to the central archival system. For the purpose of monitoring the data at reduced rate, as discussed above, a prototype of Client/Server has been developed and tested successfully. The architecture of this system is explained in the following sections.
Fig. 2. Communication between DAS Server and DAS Clients.
of data points required for plotting. The display feature separates various channels during the acquisition from the buffer that is being acquired and displays the respective data online on the host PC. In terms of hardware, this DAS unit consists of a PXI chasis with data acquisition modules connected to the PC with MXI3 controller via fibre optic connectivity of 1.2 Gbits/s transfer rate. 3.2. Client
3.1. Server The main goal of the server application is to built an application capable of invoking data acquisition on a remote PC based DAS element/server from a client within the SST1 network. The server application has been developed using TCP/IP protocol and supports multiple client connections. This application software mainly performs the job of getting configuration parameters from remote client, as also explained in Fig. 2. Depending up on the configuration parameters received from the client, the server then configures the environment of data acquisition system. It subsequently starts the acquisition using double-buffered technique. As the data is acquired in continuous manner, the data buffer read is pushed to SST-1 network along with the information of sampling rate, number of channels and the duration of the acquisition using the TCP/IP protocol. The server also has certain display features allowing the online channel separation with the option for selection of the channels and the number
Using TCP/IP protocol client application which is responsible for invoking the acquisition on the server executes the following jobs: (a) request and establishes connection to a specified host and the port, (b) sends configuration parameter to configure the PXI system connected to the server application PC and (c) starts the acquisition. The configuration parameters at present are the duration of acquisition in terms of number of seconds, device number, channel-list, and sampling rate. Client subsequently gets the data buffers, separates channels online and displays the channel data for monitoring by means of the local display features residing on the client PC. The other normal clients simultaneously get the data buffer along with the information about sampling rate, number of channels and the duration of acquisition in seconds. These clients can similarly use the local display features for displaying the relevant data. The above process is explained in Table 1 along with the corresponding data buffer size pushed on to network for monitoring. Client applications also have option to write the data to their respective hard disk.
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
1201
Table 1 Example sampling rate and the data buffer pushed on to network for monitoring Sampling rate (kHz)
Channels
Seconds
Plot local
1 5 10
32 32 32
1000 1000 1000
Yes Yes Yes
The client applications have been implemented using Labview.
4. Integration with MDSplus MDSplus is a data handling software system. Today it is being used at several fusion facilities world-wide [5–7]. MDSplus is an open source package which provides access to a built-in database, data viewer, and client/server based networking features that enable users to access data remotely. It also provides C, FORTRAN, Matlab, IDL, Java and Labview Application Programming Interface (API) to MDSplus. The above features add to the advantage of using MDSplus as the storage system for the SST-1 DAS. Using the appropriate API the data at various remote sites can be read or written without explicit file transfers. For SST1 DAS a model MDSplus tree as shown in Fig. 3, featuring the required diagnostics and their channels, has been created and tested for archiving shot data to MDSplus in the first phase of operation. MDSplus has been integrated for SST1 data acquisition using Labview. Labview virtual instruments are being used to read and write MDSplus data using the National Instruments’ Labview system. A pulse tree is created by the shot number to archive the shot data. For each plasma shot the DAS acquires data and stores the data into the MDSplus hierarchical data structure tree.
File size (MB) 128 640 1280
n/w
Buffer size n/w (KB)
Plot Clients
Yes Yes Yes
128 384 768
Yes Yes Yes
scope of DAS design or develop customized applications using the MDSplus APIs which support variety of ways including C, FORTRAN, Matlab, IDL, Java and LabView independent of any particular platform. Under the existing design of SST-1 DAS, retrieval of the shot data from corresponding MDSplus shot tree is facilitated using built in Labview and JSCOPE applications. JSCOPE [3] is a Java based program for viewing MDSplus data. One of the advantages of using JSCOPE is that multiple channels can be viewed in a single window for the data corresponding one or multiple shots as shown in Fig. 4. JSCOPE can run as client and retrieve data from remote MDSplus servers displaying multiple data for better analysis and comparison. Independent of MDSplus archive, MATLAB can be used for offline plotting and data analysis. At
5. Data retrieval A variety of options exist for the users of the SST1 who would like to access the acquired data from the central archive. With the implementation of the MDSplus hierarchical data structure and the corresponding standards, a great simplification results where the users may either use the set of standard client applications (as described above) developed under the
Fig. 3. MDSplus model tree.
1202
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
Fig. 4. JSCOPE display environment.
present matlab scripts have been generated to display the raw data from various diagnostics using the shot number.
implementation of a compression based data transport methodology.
References 6. Conclusion To summarize, in this paper we discussed the scope of the design for the data acquisition system of tokamak SST-1. Besides ensuring a correspondence between the DAS and CCS, the DAS has distributed structure based on a client/server architecture which implements various ways for monitoring, acquisition, archival and retrieval of the data using the specially designed software tools and standards of MDSplus hierarchical data structure. Further efforts are on for maximizing the throughput of the DAS, over a network which is limited in bandwidth, mainly by development and
[1] Y.C. Saxena, SST-1 team, present status of the SST-1 project, Nucl. Fusion 40 (2000) 1069. [2] MDSplus: http://www.mdsplus.org. [3] JSCOPE: http://www.mdsplus.org/javascope/ReadMe.html. [4] Labview/LabWindows: http://www.ni.com. [5] W. Davis, P. Roney, T. Carroll, T. Gibney, D. Mastrovito, The use of MDSplus on NSTX at PPPL, Fusion Eng. Des. 60 (2002) 247–251. [6] M. Cavinatoa, A. Luchettaa, G. Manduchia, C. Taliercioa, F. Baldoa, M. Bredaa, et al., Experience with RFX-mod data acquisition system, Fusion Eng. Des. 81 (2006) 1795– 1798. [7] J.A. Stillerman, T.W. Fredian, Compact PCI based data acquisition with MDSplus, Fusion Eng. Des. 60 (2002) 241–245.
Real-time acquisition and remote monitoring of steady state tokamak (SST-1) diagnostics data Manika Dey ∗ , H.D. Pujara Institute for Plasma Research, Nr. Indira Bridge, Bhat, Gandhinagar 382428, India Received 31 July 2006; received in revised form 16 January 2007; accepted 22 January 2007 Available online 23 March 2007
Abstract The architecture of data acquisition system (DAS) for the tokamak SST-1 is essentially distributed and heterogeneous. With the long discharge duration of about 1000 s, that imposes a requirement of sampling data for an equally long duration from the variety of fast and slow diagnostics, the challenge is also to cater the need of a real time monitoring of signals by multiple locally networked users. With these objectives, the DAS is based on a model where the objects of the systems are integrated with the Central Control System of SST-1 using the TCP/IP communication. Communication of each object with the Central Server is facilitated with a dedicated, 100 Mbps, fully duplex, Ethernet connection. The DAS software essentially meets the demand of an active remote configuration of hardware digitizers, like PXI system and that of the initialization of acquisition within the local network. The present work describes the TCP/IP based DAS software in labview for configuring, acquiring, and subsequently, pushing the sampled data into network. The focus is also on a client utility for real-time monitoring of SST-1 diagnostics signals by multiple clients during the discharges. We also describe the model implemented for archival and retrieval of SST-1 diagnostics data using an MDSplus server and the model tree, with its sub trees necessitated by the different SST-1 diagnostics system. In addition to this, viewing the SST-1 diagnostics signals across the network using JSCOPE and browsing the signals using Web is also described, along with a matlab plotting tool for the SST-1 diagnostics data. © 2007 Elsevier B.V. All rights reserved. Keywords: Data acquisition; MDSplus
1. Introduction The design and objectives of various subsystems of the tokamak SST-1 [1] are largely influenced by the steady-state mode of operation of the device. The ∗ Corresponding author. Tel.: +91 7923969001; fax: +91 7923969017. E-mail address: [email protected] (M. Dey).
0920-3796/$ – see front matter © 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.fusengdes.2007.01.011
scope of the data acquisition system (DAS) for SST-1 is identically wider in comparison with a finite pulsed duration operation device. The SST-1 would implement large number of diagnostics for measurement of different plasma parameters. The plasma diagnostics have requirements for both slow and fast sampling rates in a range, which varies from a few samples per second to a few MHz and the number of channels will be in the order of several hundreds. The DAS thus needs
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
to handle demands for digitization of signals, online display on the hosts, and an archival/retrieval system for post data analysis, for the entire range of slow to fast diagnostics. It also requires monitoring of data on network by different clients for slow diagnostics. The DAS has also an active interface with the Central Control System (CCS) of the device which is equally versatile and largely independent from the DAS. This interfacing between the two is to be facilitated by a well-defined infrastructure involving the communication using TCP/IP protocol. As discussed above, ensuring an exact correspondence between the DAS and CCS has been one of the objectives. While the methodology implemented is discussed further in this paper, in a typical sequence of operations, for example, the CCS passes the shot number to the DAS, which, in turn, provides the corresponding status to the CCS allowing the CCS to provide start/stop trigger to the original DAS element through the timing system. The next important aspect that falls under the scope of DAS is the management and an efficient archival of the acquired data, essentially for subsequent processing and analysis, using the established and widely used standards across the fusion community. In order to achieve this, the standard of MDSplus data archival/retrieval methodology [2] has been implemented. This, along with simplifying the post archival access, facilitates the much desired portability of the acquired data across a heterogeneous pool of, local and/or remotely located, user environments which may consists of machines ranging from the ordinary desktop PCs to the high-end workstations for extensive processing and analysis of the experimental (or even simulated) data. In addition to these, an active monitoring of client and server elements, a bandwidth effective transfer of the data across the local network and the Web, implementation and distribution of a collection of tools for online as well as offline display and simple analysis of the data, are also among the tasks that are covered by the design of the DAS. In this paper we discuss the architecture of the DAS software in Section 2 and the methodology for data monitoring is discussed in Section 3. The implementation of MDSplus standards for DAS and options for data retrieval from the DAS are described in Sections 4 and 5, respectively. A summary of the issues discussed in this paper is present in Section 6.
1199
2. Architecture of the DAS software In order to cater the wide ranging needs of the device and those of the entire user base of SST-1 DAS the architecture of the underlying DAS software is chosen to be distributed and based on the Client/Server architecture as shown schematically in Fig. 1. The main motivation behind the choice of a distributed DAS has been an improved data through-put since the multiple data transfer paths can be established which result into a net reduction in the total load on the network. There are other additional advantages like better extensibility and increased flexibility with respect to the addition of new DAS elements. The SST-1 DAS is largely a PC based DAS system each element of which is responsible for the control of its associated hardware, i.e. for digitizing the data acquired by the respective diagnostic and for the subsequent transport of the same to the central archive. The DAS softwares program various modules for different modes of acquisition, for example, either an event based acquisition or a continuous one. The DAS software uses Labview [4], LabWindows or C for Virtual Instrumentation (CVI). These essentially provide visual development environment and are largely supported, in terms of availability of the corresponding device drivers, by most of the manufacturers of PXI modules. CAMAC and PXI constitute the major part of the data acquisition system. Typically, during the process of acquisition the raw data has to be written to the local hard disk and also pushed on to the local network for monitoring by the clients which reside on the user systems.
Fig. 1. The schematic diagram of the DAS architecture.
1200
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
3. Monitoring As discharge time for the SST-1 device is aimed to be about 1000 s, it is essential to monitor the data by a continuous visualization of a part of it to observe important physical phenomena while a plasma shot is in progress. In view of this at present a dedicated monitoring system is being developed. In general, when the server sends data to different clients for monitoring it is required to be at a reduced sampling rate than the rate at which the original data is being acquired according to user requirements. An alternate way, which is being explored presently, is to transmit the entire sample to the clients in a compressed format and allow the user to select the relevant part that needs to be monitored. The Central Control System can however be supplied with the data at a relatively higher rate, depending on a particular requirement during the discharge. The entire data is simultaneously archived on the local hard drive of a DAS element for the subsequent transfer to the central archival system. For the purpose of monitoring the data at reduced rate, as discussed above, a prototype of Client/Server has been developed and tested successfully. The architecture of this system is explained in the following sections.
Fig. 2. Communication between DAS Server and DAS Clients.
of data points required for plotting. The display feature separates various channels during the acquisition from the buffer that is being acquired and displays the respective data online on the host PC. In terms of hardware, this DAS unit consists of a PXI chasis with data acquisition modules connected to the PC with MXI3 controller via fibre optic connectivity of 1.2 Gbits/s transfer rate. 3.2. Client
3.1. Server The main goal of the server application is to built an application capable of invoking data acquisition on a remote PC based DAS element/server from a client within the SST1 network. The server application has been developed using TCP/IP protocol and supports multiple client connections. This application software mainly performs the job of getting configuration parameters from remote client, as also explained in Fig. 2. Depending up on the configuration parameters received from the client, the server then configures the environment of data acquisition system. It subsequently starts the acquisition using double-buffered technique. As the data is acquired in continuous manner, the data buffer read is pushed to SST-1 network along with the information of sampling rate, number of channels and the duration of the acquisition using the TCP/IP protocol. The server also has certain display features allowing the online channel separation with the option for selection of the channels and the number
Using TCP/IP protocol client application which is responsible for invoking the acquisition on the server executes the following jobs: (a) request and establishes connection to a specified host and the port, (b) sends configuration parameter to configure the PXI system connected to the server application PC and (c) starts the acquisition. The configuration parameters at present are the duration of acquisition in terms of number of seconds, device number, channel-list, and sampling rate. Client subsequently gets the data buffers, separates channels online and displays the channel data for monitoring by means of the local display features residing on the client PC. The other normal clients simultaneously get the data buffer along with the information about sampling rate, number of channels and the duration of acquisition in seconds. These clients can similarly use the local display features for displaying the relevant data. The above process is explained in Table 1 along with the corresponding data buffer size pushed on to network for monitoring. Client applications also have option to write the data to their respective hard disk.
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
1201
Table 1 Example sampling rate and the data buffer pushed on to network for monitoring Sampling rate (kHz)
Channels
Seconds
Plot local
1 5 10
32 32 32
1000 1000 1000
Yes Yes Yes
The client applications have been implemented using Labview.
4. Integration with MDSplus MDSplus is a data handling software system. Today it is being used at several fusion facilities world-wide [5–7]. MDSplus is an open source package which provides access to a built-in database, data viewer, and client/server based networking features that enable users to access data remotely. It also provides C, FORTRAN, Matlab, IDL, Java and Labview Application Programming Interface (API) to MDSplus. The above features add to the advantage of using MDSplus as the storage system for the SST-1 DAS. Using the appropriate API the data at various remote sites can be read or written without explicit file transfers. For SST1 DAS a model MDSplus tree as shown in Fig. 3, featuring the required diagnostics and their channels, has been created and tested for archiving shot data to MDSplus in the first phase of operation. MDSplus has been integrated for SST1 data acquisition using Labview. Labview virtual instruments are being used to read and write MDSplus data using the National Instruments’ Labview system. A pulse tree is created by the shot number to archive the shot data. For each plasma shot the DAS acquires data and stores the data into the MDSplus hierarchical data structure tree.
File size (MB) 128 640 1280
n/w
Buffer size n/w (KB)
Plot Clients
Yes Yes Yes
128 384 768
Yes Yes Yes
scope of DAS design or develop customized applications using the MDSplus APIs which support variety of ways including C, FORTRAN, Matlab, IDL, Java and LabView independent of any particular platform. Under the existing design of SST-1 DAS, retrieval of the shot data from corresponding MDSplus shot tree is facilitated using built in Labview and JSCOPE applications. JSCOPE [3] is a Java based program for viewing MDSplus data. One of the advantages of using JSCOPE is that multiple channels can be viewed in a single window for the data corresponding one or multiple shots as shown in Fig. 4. JSCOPE can run as client and retrieve data from remote MDSplus servers displaying multiple data for better analysis and comparison. Independent of MDSplus archive, MATLAB can be used for offline plotting and data analysis. At
5. Data retrieval A variety of options exist for the users of the SST1 who would like to access the acquired data from the central archive. With the implementation of the MDSplus hierarchical data structure and the corresponding standards, a great simplification results where the users may either use the set of standard client applications (as described above) developed under the
Fig. 3. MDSplus model tree.
1202
M. Dey, H.D. Pujara / Fusion Engineering and Design 82 (2007) 1198–1202
Fig. 4. JSCOPE display environment.
present matlab scripts have been generated to display the raw data from various diagnostics using the shot number.
implementation of a compression based data transport methodology.
References 6. Conclusion To summarize, in this paper we discussed the scope of the design for the data acquisition system of tokamak SST-1. Besides ensuring a correspondence between the DAS and CCS, the DAS has distributed structure based on a client/server architecture which implements various ways for monitoring, acquisition, archival and retrieval of the data using the specially designed software tools and standards of MDSplus hierarchical data structure. Further efforts are on for maximizing the throughput of the DAS, over a network which is limited in bandwidth, mainly by development and
[1] Y.C. Saxena, SST-1 team, present status of the SST-1 project, Nucl. Fusion 40 (2000) 1069. [2] MDSplus: http://www.mdsplus.org. [3] JSCOPE: http://www.mdsplus.org/javascope/ReadMe.html. [4] Labview/LabWindows: http://www.ni.com. [5] W. Davis, P. Roney, T. Carroll, T. Gibney, D. Mastrovito, The use of MDSplus on NSTX at PPPL, Fusion Eng. Des. 60 (2002) 247–251. [6] M. Cavinatoa, A. Luchettaa, G. Manduchia, C. Taliercioa, F. Baldoa, M. Bredaa, et al., Experience with RFX-mod data acquisition system, Fusion Eng. Des. 81 (2006) 1795– 1798. [7] J.A. Stillerman, T.W. Fredian, Compact PCI based data acquisition with MDSplus, Fusion Eng. Des. 60 (2002) 241–245.