附录A 外文资料翻译A.1 外文Fusion Engineering and Design 71 (2004) 269–274Simulation platform for remote participants in fusion experimentsE. Barrera a, M. Ruiz a, S. López a, J. Vega b, E. Sánchez bAbstractOne of the major challenges in remote participation in fusion experiments is the control from remote locations of the data acquisition and treatment process. In an optimum situation, the remote researcher should be able to control the data acquisition configuration parameters, and data processing, specifying the r esults that must be returned to him. The simulation platform presented here, allows the researcher to develop and test complex algorithms in a high level graphical language (LabVIEW), which includes powerful data processing libraries. These algorithms will be downloaded later into the data acquisition system. Furthermore, the platform allows the simulation of hardware data acquisition, which include the following points: (a) simu lation of channel configuration from one or several data acquisition cards (channels used, sample frequencies, etc.), (b) generation of buffered simulated data (it is also possible the use of raw data, acquired in previous experiments, as simulated data), and (c) reproduction of hardware behavior (except, of course, in terms of real time behavior and real data). For this purpose, Virtual Instruments (VIs) libraries written in LabVIEW will be provided to the remote developers. These VIs will be replaced later, in the data acquisition system, by their homologous VIs that actually interfaces with the hardware. This facility will allow remote researchers to verify the correct behavior of their own data processing algorithms before downloading them into the data acquisition system.Keywords:Remote participation; Simulation; Data processing; Code testing; Fourth generation language1.IntroductionThe development of a remote participation system is one aim of the recent TJ-IIdata acquisition improvements. This device is located at the Centrode Investigations’ Energéticas Medioambientales y Tecnológicas (CIEMAT) of Madrid [1]. In this sense, efforts have been focused on three main points: security of the transactions, development of specific hardware and software in order to provide real time data processing capacity to the system, and the design of a simulation platform that allows researchers to develop and test data processing algorithms, simulating the remote acquisition system. This article describes the main characteristics of this simulation platform.The aim of the development of simulation software is to offer to the remote participants, a system on which they can verify the correct behavior of their data processing programs without working directly on the real data acquisition system. In this way, they can validate their own developments before loading the code on the final system [2].In order to achieve this, several more concrete goals have been defined:●Developing a simulation platform that allows generating data with different characteristics. This platform will simulate real data acquisition system.●Offering a utilities library that communicates the simulation platform with the user transparently.●Providing mechanisms to make the users data processing programs work on the simulation platform as well as on the real data acquisition system, in a way that is transparent to the user.2. System architectureThe system has been developed using the high-level fourth generation language LabVIEW of National Instruments. This language includes powerful data processing libraries that allow researchers to develop in a simple and efficient way, their own data processing algorithms [3].The architecture of the simulation platform can be divided into two main blocks:●The simulator, which is responsible of simulating the behavior of the data acquisition system and also of generating signals with different characteristics.●A utilities library developed using LabVIEW that allows the management of the buffers in the data acquisition processes.2.1 SimulatorThe simulator is made up of four modules: Simulator-Config, Simulator-Start, Simulator-Read and Simulator-Clear. These modules receive the request of a newacquisition, the beginning of the simulation, the reading of data and the release of the used resources, respectively. Each one of them is independent and runs in a parallel way with the others. The communication and synchronization between the modules is done using global variables which access is controlled by semaphores.The configuration of the simulator requires the following operating parameters ：●Definition of the number of channels, buffer size and sampling rate.●Definition of a data base that contains the users’ identifiers (ID) and which channels are associated to each one of them. The simulator works in a multi-user way, this makes it necessary to define which channels are being used by each user program that interacts with the simulator. This is described more deeply in Section 2.2.●Definition of the type of signal that will be used in each channel. The simulator is able to generate nine different signals: sine, square, triangle, sawtooth, periodic random noise, Gaussian white noise, uniform white noise, formula (this option allows for the possibility of generating a signal from a mathematical expression) and file waveform (this option allows the possibility of generating a signal from the data stored in a file, which could allow the simulator to work with data taken form previous acquisitions).●Definition of the par ameters of the signal associated to each channel. According to the type of signal, it will be necessary to define some of the following parameters: frequency, offset, phase, standard deviation, formula, path (for file waveform), amplitude, increase amplitude (this parameter indicates whether the signal’s amplitude should be increased with time or not) and increase (factor in which the signal’s amplitude should be increased).Once the simulator has been configured, it remains ready to communicate with the users applications that have been developed using the utilities library that was offered.2.2 Utilities libraryThe utilities library provided to the user has been developed using a similar methodology to that used in the data acquisition libraries supplied by LabVIEW. This library is made up by high-level modules that offer a great transparence in the behavior of the system to the user. This will allow researchers to develop applications that work with the data acquisition systems in a simple way and without needing a deep knowledge of this programming language.The utilities library is made up by four modules:●AP Config: module in charge of requesting the configuration of the suitable channels for the user’s identifier (ID).●AP Start: module in charge of requesting the beginning of the acquisition for the channels of the ID.●AP Read: module in charge of sending the request of reading to the simulator and receiving the requested data.●AP Clear: module in charge of requesting the release of the resource that were used to carry out the acquisition for the received ID.Using these four modules, the user would be able to develop an application which code diagram was similar to that shown in Fig. 3. The input parameters to the user’s application will be three: the user’s identifier (ID), which should match up with one of the IDs defined in the simulator and that will identify the channels in which the simulator is going to receive samples. The second parameter is the complete number of samples that will be received in the channels previously mentioned (percentage of scans). Lastly, the third parameter is the size in which the data will be received (percentage to read).Starting from the user’s identifier (ID), the AP Config module will request the simulator to configure the channels associated to that identifier. After this has been done without errors, the AP Start will request the simulator to start the acquisition in the indicated channels (of course in this case it will be a simulation, not an acquisition). O nce the acquisition has begun, the user’s program will enter a loop in which it will carry out consecutive readings of the data returned by the simulator through the AP Read module. It is at this point where the user must introduce its own data processing algorithms (that will substitute the generic module “My Process” shown in Fig. 3). Once the acquisition has finished (simulation in this case) the AP Clear module will release the resources used by the simulator.3. Simulator and utilities library synchronizationThe development of both the simulator as well as the utilities library have been done to allow the possible parallel execution of several user programs that would be communicating with the simulator and receiving data of it. In this way, the simulator is able of giving service to several applications developed by the user simultaneously. Each application will have different user’s identifiers (IDs) and may use one or several channels (defined in the configuration of the simulator) and obviously, eac h application may have a different processing over the data.In order to enhance the synchronization between all the user’s programs and the simulator, the synchronization functions Queue of LabVIEW (Obtain Queue, Enqueue Element, Preview Queue Element, Dequeue Element and Release Queue) have been used. These functions allow sending control messages as well as data messages between different modules or LabVIEW Virtual Instruments (VIs). The usage of these synchronization functions enhances the efficiency o f the final application and increases the integrity of it, since it makes the running of the simulator independent of the utilities library. Therefore the utilities library does not need to have any access to the global variables used by the simulator. This reduces the complexity of the access control protocols to these variables and, moreover, it increases the integrity of the system since the utilities library cannot change, in any case, the value of the simulator’s variables. There again, using the queu es managing functions, increases the efficiency of the application since any module of interaction between the simulator and the utilities library stays in an idle state until it receives any data on its queue.4. Integration in thefinal systemAt the moment, the team that has developed the simulation platform is working on the integration of the user’s application in the final system. The goal of this integration is to guarantee that a user’s application, as it has been defined in previous sections, can be run on the real data acquisition system [4] (in this case, on the data acquisition system in the TJ-II device located at the Centro de Investigations Energéticas Medioambientales y Tecnológicas (CIEMAT) of Madrid), without any modifications on its code. Th is involves the development of a resident application in the final data acquisition system that integrates, manages and synchronizes all the user’s applications. Moreover, the utilities library should be modified to make it identify whether it is being run on a user machine together with the simulator or in the final system. In both cases, it should make the suitable calls to the modules that communicate with the simulator or to the modules that LabVIEW offers to communicate with the hardware in the data acquisition system.The simulator and the utilities library have been developed specifically for the TJ-II device. Nevertheless, these modules are sufficiently generals as to be used in other fusion devices that include LabVIEW.A.2 译文在核聚变实验中的远程控制仿真平台摘要在聚变实验中的远程控制主要挑战之一是对来自偏远地区的数据采集和处理过程的控制权。