The complexities of monitoring and controlling the various DIII-D Tokamak systems have always required the aid of high-speed computer resources. Recent upgrades in computer hardware to the DIII-D central operations and Neutral Beam computer systems have forced a redesign of the corresponding software. These newer systems cannot make use of the antiquated computer platforms of the past. Entirely new software has been written/installed to replace the old. During the design and development many newer features have been added; especially in the realm of Graphical User Interfaces and database management. For most of the systems involved, this required the implementation of a third party software, including a crucial package written by AccessWare Inc. of Houston Texas

Penaflor, B.G.

Phillips, J.C.

Piglowski, D.

Penaflor, B. G.

Phillips, J. C.

UNT Digital Library

G A-A22745 CONF- 77 j 06 5 - USE OF THE ACCESSWARE INTERFACUDATABASE SOFTWARE IN THE NEUTRAL BEAM CONTROL SYSTEMS USED BY THE DIN-D TOKAMAK by D. PIGLOWSKI, B.G. PENAFLOR, and J.C. PHILLIPS 19980402 075 e$$.+ G€N€RAL ATOMICS G A-A22745 USE OF THE ACCESSWARE INTERFACUDATABASE SOFTWARE IN THE NEUTRAL BEAM CONTROL SYSTEMS USED BY THE DIII-D TOKAMAK by Da PIGLOWSKI, B.G. PENAFLOR, and JaC. PHILLIPS This is a preprint of a paper to be presented at the 17th IEEElNPSS Symposium on Fusion Engineering, October 6-1 1, 1997, San Diego, California and to be published in the Proceedings. Work supported by the U . S a  Department of Energy under Contract No. DE-AC03-89ER51114 GA PROJECT 3466 DECEMBER 1997 GENERIlL ATOMICS Use of the Accessware Interfacematabase Software in the Neutral Beam Control Systems Used by the DIII-D Tokamak* D. Piglowski, B.G. Penaflor, and J.C. Phillips General Atomics P.O. Box 85608, San Diego, California 92186-9784 Abstract - The complexities of monitoring and controling the various DIII-D Tokamak systems have always required the aid of high-speed computer resources. Recent upgrades in computer hardware to the DIII-D central operations and Neutral Beam computer systems have forced a redesign of the corresponding software. These newer systems cannot make use of the antiquated computer platforms of the past. Entirely new software has been writtedinstalled to replace the old. During the design and developement many newer features have been added; especially in the realm of Graphical User Interfaces and database management. For most of the systems involved, this required the implementation of a third party software, including a crucial package written by Accessware Inc. of Houston Texas. INTRODUCTION The DIII-D Tokamak is part of an on-going national research program under the auspices of the United States Department of Energy DOE). This facility, located in San Diego, California, at General Atomics (GA), has provided an experimental environment for plasma and fusion research for over ten years. Recent technological leaps in computer design and manufacture have created an incentive to modernize and build upon the older computer systems which controlled and acquired data at DIII-D. Among these are the computer systems that are used by the Neutral Beam Systems (NBS) which are used to heat the plasma in the Tokamak. The beam systems, when working alongside normal DIII-D operations, can provide up to 20 M W  of deuterium neutral beam heating to the interior of the Tokamak vessel [I]. Past control and data acquisition were performed by four independent computer systems designed and installed prior to the begining of the 1980s. As part of an overall upgrade to the DIII-D facility, these four individual computer systems have beem replaced by two smaller, yet faster, up to date machines. This allows all those involved to take advantage of more modern computer capabilities. The three main objectives of this paper are to 1) present a brief overview of hardwarekoftware changes to the main computing resources and the control systems; 2) describe the design and structure of the resulting software systems; 3) evaluate the benefits and drawbacks of the systems. HARDWARE CONFIGURATION The original layout of the NBS used four MODCOMP Classic single processor real-time machines. These handled control, data acquisition, and data analysis for all eight NBS. Replacement of the four MODCOMP computers seemed imperative by the early 1990's. Although reliable and useful in the past, these machines were now outdated, slow, and expensive to maintain, both in manpower and hardware costs. The extensive investment in CAMAC at DIII-D constrained any new computers which were to replace the old MODCOMPs. Certain logic circuits were retained from the previous Mode/Control System (MC) [2]; slight interface changes would undoubtably have to be made. Most communication between these existing systems would still need to be handled via CAMAC modules. Operator controls, involving a complicated set of switcwdial panels, would need to be greatly simplified or elimitated entirely. Two MODCOMP/AEG based machines replaced the four older units. With the capabilities such as graphical user interfaces (GUI) and local database access, the configuration of the NBS changed significantly. Some portions of the old configuration were maintained in an attempt to minimize the conversion time and lessen the development of new software needed to reach an operational status. These new machines handle the familiar tasks of data acquisition, storage, and control for example, and resources have been condensed from four down to two machines. Further simplification in the overall system was made by internalizing operations protocol with logic programming, replacing the old operator switch panels with G U S ,  and increasing local magnetic disk storage space [3]. Fig. 1 shows the current status of the NBS computer systems. The initial priorities for the NBS upgrade was to improve upon maintainability of the system itself. Performance and data storage were secondary [4]. Once these new systems were stable all these objectives were easily met with the new hardware. *Work supported by US. Department of Energy under Contract No. DE-AC03-89ER51114. GENERAL ATOMICS REPORT GA-A22745 1 I CAMAC I computer computer El +, pkl Archive Fig. 1. Basic NBS configuration. NEUTRAL BEAM SYSTEM COMPUTING CAMAC constraints (as mentioned above) and a near real time environment hindered the choice of better performing and perhaps cheaper computing solutions. A real-time operating system in itself is a compromise with the flexibility and availability of other operating systems which are standard on most computer platforms. Certain vendors could not fullfil1 these two constraints and that narrowed the final selections. The resulting systems are each single processor CPUs based on a Motorola M88 110. The operating system (OS), REALIX, is a stripped down standard UNIX OS with both TCPm and NFS capability. SCSI and VME interfaces for peripherals and devices are used. Although not cutting edge technologically, even at the time of their purchase, they are more than adequate for the current task and for the near-term future of the NBS. The REALIX environment allows for "open" development of software. Common UNIX utilities are present on both systems which were a welcome change from the narrow and infexible tools of the old MODCOMP computers. High level programming languages like C, FORTRAN and shell scripts made development easier than the little known proprietary programming resources of before. However few third party vendors are willing to provide auxiliary software for this unique operating system. For example, the most common relational databases, those which are SQL based, are not available. Also GUI builders and some device drivers are hard to find. It may be debatable whether a real-time environment for the main computers is even neccessary. Real-time access and control are, for the most part, done by micro-processors and sub-systems [5].  ACCESSWARE INTERFACE AND DATABASE DESIGN MODCOMP provided a third party software house whose product line would integrate the sub-systems of the NBS with its own database system and graphical display modules. This company, Accessware Inc., provided not only these two crucial aspects for a modern control system but also a means for inter-machine communication and process control. Essentially the Accessware set of utilities provide a series of X-window displays which allow users to view collected data points and initialize certain actions by standard point and click methods. This requires a flexible database. The NBS system contains some 4000 individual data points. Common database values may involve anything from operator defined set points, both analog and digital feedbacks, to current hardware states. The organization of the information, both in the database itself and on any individual display window is left to the developer. A thoughtful interface to the database as well as a screen builder has been provided. Customization 05 any processing, those actions which are invoked by user responses or alterations in most database values, are handled by a library of programmed routines. These too are left to the control of a developer. The eight NBS sources can be broken down into two groups of four. Historically this has been done because of power supply, beam location, and the demands of operator interaction. Within each group of four, operation of each beam source is quite similar. The design efforts for the 2 GENERAL ATOMICS REPORT GA-A22745 control system exploit this feature. The various aspects of the control system (database entries, display windows, control software, etc.) are shared or are so similar that during creation they are a mere copy of the original. For this reason, a description of one Neutral Beam Source, should suffice and in fact during development most things were created and tested for one source and then permutated out to the remaining sources for that machine. The entire developed system was then duplicated on the alternate computer. Operation of a Neutral Beam source centers upon a “shot cycle.” Each cycle consists of several progressive steps, under the direction of an operator, which utlitmately results in the firing of the beam source. The operator has directly under hisher control crucial setpoints such as power level and beam duration. He/she has under their control the ability to manually force specific hardware settings which have failed on the first attempt and which may be holding up the shot cycle. Data collection occurs at various points along the cycle. Momentary values, those data points which have meaning at a specific time in the shot cycle or those points are of concern at an instance during the shot, are readoutputed at specified times. Other values, for example feedbacks, are scanned continously throughout the shot. Organization of the database itself is broken down by sub- groups. All database points are divided along the lines of input or output. Accessware allows for even further sub- division by the variable‘s defined purpose, type and precision. Individual data points for the NBS are related by type/purpose first and then by beam source; i.e. digital outputs for source 330 left, analog inputs for 150 right. This is extremely convenient since blocks of variables that are related by beam source were copied and then the source relation altered. It was also easy to group like variables close together since their location in the database, their “index,” would enable certain assumptions to be made when interfacing to individual database entries. Some 500 points are needed for each source. The vast majority of these are scanned momentary input variables. Control of the actual hardware is accomplished by digital and analog outputs. These either denote setpoint values or toggle the hardware between two or more states (on/off being the most common). The timing of actions taken in the shot cycle is governed by a linear order since steps are often dependent upon the successful completion of the previous step. Initialization of a shot cycle may be done by the operator or by the central tokamak control system. Prematurely terminating a shot cycle, may be done by the operator or central control system in the same manner. Once the shot cycle has been started very little interaction is required by the operator unless problems arise. The automated shot cylce is intentionally halted only once during the remainder of the shot. This allows for the beam source to remain in a waiting state until a “fire” command is given. This command, as do the start-up and termination commands, is given by the operator or in most cases by the central tokamak control system. It should be noted that controls of the shot cycle during normal operations is handled by the Tokamak control system, which oversees the NBS as well as other key systems. A main or top level screen gives the operator access to the series of displays set-up for monitoring of individual beam sources. Groups of beam specific displays are housed under a central operator screen which allows for quick reference of sub-systems and important operational values. These of course are grouped and related by neutal beam source and procedural step. Each window makes full use of text fields, color bardgauges, and status lights for easy visual discernment of data. Fig. 2 shows a main NBS display and corresponding operator screen for beam source 150 right. SHORT COMINGS OF ACCESSWARE The Acessware software, designed with many aspects of industrial monitoring and control in mind, did not readily adopt itself to the DIII-D NBS. A device driver for CAMACREALIX had to be created. Also Accessware‘s Shot73045 UNAV UNAV TEMP PEAK 150 RIGHT= MAGNET-LOUVERS f MAGNET ENTRANCE COLLIMATORS 1 MAGNET POLE SHIELDS 0.0 959.0 11.0 961 .o 1 .o 963.0 RETURN SCRAPER 10.0 953.0 MAGNET LOUVERS 2.0 955.0 11.0 957.0 11.0 Fig. 2. Typical operator screen. 2 12.0 965.0 5.0 965.0 10.0 969.0 I GENERAL ATOMICS REPORT GA-A22745 3 programmable “actions” execute sequentially; one after another. This method could not take full advantage of the multi-task REALIX environment and was of great concern when questions of performance arose. This is especially apparent when dealing with four individual Neutral Beam sources during a single DIII-D shot cycle. Auxillary software was created in-house to deal with both issues. A seperate stand-alone program was ported from the DIII-D data acquisition system to handle all CAMAC input and output (YO). The function of this software was to be no different than that performed on the acquisition system. The data acquisition system is also a MODCOMP/AEG computer running the REALIX OS so no anticipated problems or redesign issues were encountered. In fact, the demands on CAMAC are considerably less for the NBS than the acquisition system. A robust CAMAC interface prevented a good deal of wony as the full NBS was in developement. Customized NBS actions were designed into a compact set of stand-alone programs refered to as “procedures.” These monitor and interact with the Accessware Real-time Database. As values in  the database are altered, they trigger specific procedures which in turn perform the specified step required in the NBS control sequence. It is within these procedures that the meat of the control system resides. The “actions” portions of Accessware, the only programmable area of Accessware, is ineffecient to handle a complicated set of tasks. It was advised that these “actions” be utilized for only the simplest of things. They are thereofre used for a few manually invoked “procedures.” CONCLUSION The success at bringing on-line the recent computer upgrades for the NBS has eliminated the problems of maintenance and updating of the old system and provided new capabilities. The operators and users continue to become more familiar with the new interfaces and expanded capabilities of the modernized control system. This however has been tempered by continued development and redesign of some features. The amount of time needed for initial development was longer than expected. Problems and idiosyncrasies encounterd during design and implementation were worked through. Serious problems were found in the Accessware software. Most solutions were designed and written in-house. To this day, Accessware has yet to address these issues and this brings into question the viability of their entire package. With the capabilities of faster data collection and cheaper storage devices, demands on the system will grow. It is inevitable that the NBS will have to adapt to the changing times. The current NBS is a good base to build upon as DIU-D and the neutral beam systems evolve. ACKNOWLEDGMENTS I would like to thank the personnel at the DIII-D facility who aided me in the preparation of this paper. A special thanks is extended to Ben Penaflor and Bill McHarg who’s insight into the DIII-D systems is appreciated. I would also like to thank Jeremy Phillips, Dan Kellman and the rest of the neutral beam group for their continued support. REFERENCES [l] J.C. Phillips et al., “Advances in the operation of the DIII-D neutral beam computer systems,” unpublished. D. Kellman and R Hong, “Recent improvements to the DIII-D neutral beam Instrumentation and control system,” unpublished. B.G. Penaflor et al., “Software development on the DIII-D control and data acquisition computers,” unpublished. P.A. Henline, ”Use of open systems for control, analysis, and data acquisition of the DIII-D tokamak,” GA Technologies Report GA-A21403, 1993. [5] G. Bramson, “DIII-D timing system,” IEEE Transactions on Nuclear Science, Vol. NS-34 No. 4, 1987. [2] [3] [4] 4 GENERAL ATOMICS REPORT GA-A22745 M98003186 I11111111 Il 11111 lll 11111111 lll l11111 Il1 Il1 Report Number (14) re I4 -- Q=za7+5- C O N F - - 9 7 /  8 6,5-- - 'ubl. Date (11) / Y 9 7  Sponsor Code (1 8) JC Category (19) ooEIEe 1 M LA 99a DOE 

Use of the Accessware Interface/Database Software in the Neutral Beam Control Systems Used by the DIII-D Tokamak

Abstract

Similar works

Full text

Available Versions

UNT Digital Library